ооп, иерархии, подмножества

Я не уверен, что написание горы canEqual, hasEqual, shouldEqual, approxEqual итп есть правильная «таблица умножения»,

Конечно неправильная.

о да, иметь несколько EQ, EQL, и т.п. конечно лучше ))

Ведь даже в POSIX: наследование файл->каталог, файл->сокет хотя к сокету или каталогу применимы не все операции с файлом.

А олени Plan 9 лучше !

категории виджетов там строятся не на классах, а на совершенно сбоку приделанной метаобъектной системе со своей отдельной иерархией, свойствами (properties) слотами и сигналами.

к которой ещё нужен отдельный метакомпилятор moc который конпелирует этот метаобъектный протокол в C++ VTABLE модель.

Я знаком и с популярной (крестовой) моделью ооп, и со смолтоковой, и со странными, в т.ч. самописными моделями экспериментировал, но все они все отличались формальной жесткостью. То есть инкапсуляция она либо есть, либо ее нет, например. Когда ты берешь чужой ооп-класс или набор оных, ты опираешься на публичный интерфейс, а внутрь лазить нельзя, т.к. детали реализации долго не живут. Но при разработке собственного продукта ты волен опираться на эти детали, т.к. сам варишься в этом супе (даже юникс-фс имеет ugo и acl, ну вы понели). С одной стороны, это хорошо, когда все формализовано, но иногда хочется включить первую передачу и форсировать проблему, взять ее грубой силой, и в жесткой модели (а мы связаны границами классов/интерфейсов) ты теряешь полезные по сути своей инструменты валидации, делая например полупубличный доступ к тому, что является частью инварианта системы, размазывая его по коду без к-л семантического контроля. Хорошо говорить об абсолютной стройности, но все знают, что есть такое слово дедлайн, кроме того некоторые вещи невозможно красиво формализовать в ооп-модели, да еще с обычными ограничениями языка (там неймспейсов нет, тут базового класса). Интересно было бы пощупать ооп, в котором структурные границы задавались бы не жестко-синтаксически, а путем описания инвариантов и возможностей схемы, например не указывать вовсе public/protected, а также управлять областями видимости (сейчас это куцый friends), делать умные интерфейсы, которые знают о твоем наборе внутренних свойств и т.п. Причем не жестко, а просто с показателем «говнокодности» участка.

В общем-то тот тред был как раз о редакторе, который позволил бы управлять этим всем графически естественным образом, например контролировать вложенность декларативных контекстов, где внутри все друг-друга видят, а снаружи не очень, причем не как жесткое правило, а как статистика: в этом контексте 5 красных использований (читай нарушение инкапсуляции), а между этими двумя их нет. Я уже на своем опыте убедился, что прототипирование лучше делать на слабой схеме (перл и т.п.), а продукт писать на сильной. Как сделать так, чтобы прототип можно было детализировать и рефакторить прямо по месту, оставляя непродуманные места тупыми хаками — вот основной вопрос. Кроме того я там описывал, как можно упростить код путем уменьшения too wordy, и еще пару интересных мелочей, но это больше следствия.

Кратко так: почему нет уровней доступа, почему не компилируется быдлокод, заставляя меня ломать модель, а не идти к ней шагами, почему мне всему надо придумывать дурацкое уникальное название, которое точно не будет иметь смысла в другом контексте.

зы: Я не претендую на мегавидение и прорыв, и на 98% уверен, что генерю тупняк, но мне интересна эта область и почему в ней так, как сейчас, а не по-другому.

Eiffel смотрел? Там есть инварианты, пост-условия и пред-условия, вместо friend механизм, позволяющий указывать, кому(каким иерархиям) и что(какие разделы класса) ты открываешь.

Вроде не смотрел, на досуге гляну, спасибо.

Но там таки ООП с классами. Так что может тебе и не интересно.

Используй C++, там есть то что тебе надо и даже с избытком, отчего и проблемы у С++. Проблема решается при помощи таких умных слов, как наследование (дополним класс чем-то новым и назовём его иначе), полиморфизм (функция делала одно, а в наследнике будет делать другое), инкапсуляция (прячем мусор в виде реализации всего этого от программиста-пользователя), виртуальные функции (а вот их поведение мы и поменяем в наследнике), дружественные функции (они имеют доступ к приватным поялм и методам класса и при этом не наследуются) и собственно сами классы.