Чтобы добавлять сообщения и комментарии, .

@OCTAGRAM:
OCTAGRAM

putting.om.Environment.solveMetaclassConstraints
Нашёл ту функцию, которая подбирает нужный метакласс или конструирует новый, если ни один из запрошенных не подходит. На всё про всё 40 строк кода. Вот, насколько упростил Гвидо ван Россум свой Питон, отказавшись это сделать, и сломав метаклассы по сравнению с моделью из книги, которой он вдохновлялся.

The metaclasses book describes a mechanism whereby a suitable metaclass is automatically created, when necessary, through multiple inheritance from M1 and M2. In Python 2.2, I have chosen a simpler approach which raises an exception if the metaclass constraint is not satisfied; it is up to the programmer to provide a suitable metaclass through the __metaclass__ class variable. However, if one of the base metaclasses satisfies the constraint (including the explicitly given __metaclass__, if any), the first base metaclass found satisfying the constraint will be used as the metaclass.

@OCTAGRAM:
OCTAGRAM

Unifying types and classes in Python 2.2
One of the coolest, but perhaps also one of the most unusual features of the new classes is the possibility to write "cooperative" classes. Cooperative classes are written with multiple inheritance in mind, using a pattern that I call a "cooperative super call". This is known in some other multiple-inheritance languages as "call-next-method", and is more powerful than the super call found in single-inheritance languages like Java or Smalltalk. C++ has neither form of super call, relying instead on an explicit mechanism similar to that used in classic Python. (The term "cooperative method" comes from "Putting Metaclasses to Work".)Таким образом, в этом отношении Питон продвинулся вперёд по сравнению с SOM. В реальном SOM множественное наследование было реализовано как в C++, топорно и без всяких порядков вызова методов. Соответственно, никакого call-next-method, а вместо этого указатель на унаследованную реализацию получался единоразово во время инициализации класса, либо потом можно было запросить его ещё раз, указав свой класс и индекс родительского класса. Эмиттеры все эти индексы заворачивали в соответствующие имена родительских классов. При этом во весь вставала проблема ромбовидных иерархий, когда к родительским классам вызовы могут либо не приезжать, либо приезжать несколько раз. Чтоб совсем плохо не было, конструкторы, деструкторы и операции присваивания в SOM пользовались битовыми полями (один класс — один бит), отсекающими повторные вызовы. Кооперативные методы, скорее всего, были только в книге. Metaclass Framework в составе SOM был закрытой библиотекой без IDL. Бетатестеры могли получить их по запросу. Так как всего этого нет, однозначно утверждать, что MRO не было, нельзя, но по крайней мере, в общем доступе кооперативных методов не было. До Питона они были только в книге.

The metaclasses book describes a mechanism whereby a suitable metaclass is automatically created, when necessary, through multiple inheritance from M1 and M2. In Python 2.2, I have chosen a simpler approach which raises an exception if the metaclass constraint is not satisfied; it is up to the programmer to provide a suitable metaclass through the __metaclass__ class variable. However, if one of the base metaclasses satisfies the constraint (including the explicitly given __metaclass__, if any), the first base metaclass found satisfying the constraint will be used as the metaclass.А вот тут, к сожалению, сделан шаг назад к семантике CLOS. В SOM 2.0 это было, и, конечно, это было в книге. Возможно, что (кроме длительной недоступности книги, пока я её не отсканил) это причина, почему метаклассы в Питоне не столь развиты. Ведь с таким геморроем ими резко становится не так удобно пользоваться.

@OCTAGRAM:
OCTAGRAM

J. Hamilton. A model for implementing an object-oriented design without language extensions
Почитал. Выходит, селекторы должны указывать на смещение внутри таблицы виртуальных методов, а эти таблицы в общем случае должны предусматривать селекторы вообще для любого метода любого класса, а то, что на самом деле там их меньше, — это оптимизация. Этот доклад ссылается на объектные модели Smalltalk и Objective-C, в которых одиночное наследование, при этом ссылка на этот доклад найдена в книге «Programming with DirectToSOM C++», где модель однозначно поддерживает множественное наследование. Однако, в принципе, понятно, как применить одно к другому. В случае Smalltalk и Objective-C объектная модель плоская, допускающая коллизии между селекторами никак не связанных между собой классов, и именно разруливанию этих ситуаций посвящён доклад. А в SOM одноимённые методы классов так конфликтовать не могут, поскольку жетоны методов функционально эквивалентны кортежу из ссылки на класс-объект и имени метода. Однако конфликт возникает в другом месте, если мы пытаемся сделать у каждого класса таблицу виртуальных методов с поиском по индексу. Любое множественное наследование приводит к тому, что на один и тот же слот в таблице виртуальных методов начинают претендовать не подозревавшие о существовании друг друга классы, у которых появился общий потомок. В этом случае можно таблицы виртуальных методов родительских классов раздвинуть так, чтобы потомки не могли конфликтовать, и уже без проблем произвести таблицу виртуальных методов наследника. Приходится попариться при создании классов, зато потом всё летает. Хотя я ещё не исследовал перемычки SOM и не знаю, как оно там было на самом деле.

@OCTAGRAM:
OCTAGRAM

Approaches to Composition and Refinement in Object-Oriented Design
MN93 shows that framework refinement (in the sense of adapting a frame-work to yield another abstract framework) is not possible under either co-variant(Eiffel) or contravariant (Modula-3) typing rules.Надо бы как-нибудь ликвидировать свою безграмотность по части ковариантного и контравариантного вот этого всего.

@OCTAGRAM:
OCTAGRAM

По результатам плотной работы с SOM обнаруживается горькая правда, что множественное наследование там не как в «Putting Metaclasses to Work», CLOS, Dylan и Python, а как в C++. Линеаризации классов, порядка разрешения методов просто нет. Можно либо вызывать только первого родителя среди тех, кто поддерживает метод, либо какого-то конкретного, либо всех, и тогда в ромбовидных диаграммах наследования кому-то будет прилетать многократно. Конструкторы, деструкторы и операция присваивания, чтоб совсем плохо не было, защищаются битовыми полями. Я их и раньше видел, но мне казалось, это связано с тем, что конструкторам может требоваться передавать управление в нестандартном порядке, а обычные методы просто вызовут, что им дал somParentResolve, и попадут куда надо. Эдак довольно солидная часть книжки становится неприменимой к имеющимся бинарникам. То, что описано в книге как то, с чем авторы имели опыт, действительно было таковым, но в общий доступ не попало:
SOM DTK v3.0 Programming Guide на странице 205 (187):
Customizing method resolution requires the use of metaclasses that override SOMClass methods. This is not recommended without use of a Cooperation Framework that guarantees correct operation of SOMobjects in conjunction with such metaclasses. SOMobjects users who require this functionality should request access to the experimental Cooperation Framework used to implement the SOMobjects Metaclass Framework. Metaclasses implemented using the Cooperation Framework may have to be reprogrammed in the future when SOMobjects introduces an officially supported Cooperation Framework.

@OCTAGRAM:
OCTAGRAM

Раздраконил свой генератор привязок до такого состояния, что уже заработала программа, использующая исключительно новые привязки. Это пример для старых привязок, а это — для новых. В старых привязках SOMObject — это указатель на запись, а все остальные классы — синонимы SOMObject, то есть, контроля типов нет. В старых привязках, чтобы узнать тип аргумента, нужно было в процедурном стиле написать ParameterDef__get_type, а вот имя аргумента объявлялось в Contained, поэтому Contained__get_name, а так как вручную мне лень синонимы везде прописывать, то только по таким именам работало. В новых привязках генератор собирает все методы класса в одну общую кучу, и всё работает достаточно очевидным образом с вызовом методов через точку. И даже атрибуты CORBA спроецировались на свойства Delphi. Поскольку в Delphi жалкое одиночное наследование, генерить список методов требуется каждый раз сначала, и именно это и делается, зато потом удобно.

Работает это посредством того хака, что создаются объекты SOM, а Delphi думает, что это объекты Delphi. Так как с точки зрения Delphi методы статические, Delphi не лезет в VMT, делает статический вызов, в нём написан код, который направит вызов в SOM, и оно там пойдёт куда надо. Ещё немного пошаманил, чтобы волшебным образом работали классовые функции. Классовые функции могут вызываться как у объектов, и тогда Delphi пытается взять из объекта VMT по нулевому смещению, а может — непосредственно у класса, и тогда берётся статический адрес VMT. Учитывая, что с точки зрения Delphi классы друг от друга не наследуются, отличить эти случаи не сложно. Нужно просто сравнить Self со своим именем, и если да, то нас вызвали через имя класса, и класс-объект нужно искать одним способом, а если нет, то нас вызвали как метод объекта, и надо ещё раз разъименовать Self, и там будет лежать указатель на класс-объект.

Немного подкрутил, чтобы в результате метода SOMObject.somGetClass учитывался метакласс. Была мысль вообще все методы метакласса спроецировать на классовые функции и процедуры, но потом посмотрел, сколько там всего в SOMClass, и решил, что не надо. Тем более, что в SOM.IR публично показан только один метакласс, SOMMSingleInstance. Но даже ради него подкрутил, чтобы у метода SOMObject.somGetClass возвращался именно указанный метакласс, а не просто SOMClass. Кстати, так получается, что с точки зрения языковой проекции метаклассы не могут так просто наследоваться. То есть, умом-то мы понимаем, что компилятор SOM гарантирует совместимость метаклассов, но вот во что это спроецировать, открытый вопрос. Если мы наследуемся от двух классов с разными метаклассами, то метакласс потомка будет заведомо принадлежать пересечению множеств потомков каждого метакласса, и что, для этого динамически создаваемого метакласса тоже создавать привязки? А там по цепочке ещё для метаклассов более высокого порядка может потребоваться автоматическое создание. Одно дело — когда движок SOM это создаёт, и другое дело — когда генерится текст. Я решил, что этого делать не нужно, а раз так, то даже, если был класс A с указанием метакласса M_A, и от него наследуется класс B, то, если B не укажет явно тот же метакласс, что и A, в его привязках будет опять обычный SOMClass.

Естественно, все методы обычного TObject не будут работать. Я эту проблему пытаюсь решить, скрывая их при помощи reintroduce в private. Только операция as портит картину. Её не спрячешь, но хотя бы заменил методами, приводящими тип вверх и вниз. Вот так, с небольшой порцией магии создаётся впечатление, что SOM в Delphi как родная. Классы, методы, свойства.

@OCTAGRAM:
OCTAGRAM

Про интерфейсы и классы:
В COM замороженность интерфейсов диктовалась техническими ограничениями, во всяком случае, это то, что на виду. Однако, если присмотреться, то даже в виртуальных машинах, сценарных языках программирования и т. п. окружениях, где технические проблемы решены, мы не можем просто взять и расширить интерфейс, так как интерфейс может быть реализован вообще каким угодно классом, и не согласованные с другими командами разработчиков расширения интерфейса сломают их классы. А вот если есть класс с реализацией по умолчанию, то этот класс можно расширять, и все довольны. Так приходим к мысли о том, что множественное наследование всё–таки нужно, а так называемое «множественное наследование только для интерфейсов» — это пыль в глаза. На самом деле нет, а звучит как будто есть.

Естественно, под множественным наследованием я не имею в виду убожество из стандарта C++.

@mabu:
mabu

Основополагающий принцип ООП: код и данные вместе. И уже к нему цепляются прочие прелести типа наследования, полиморфизма и тому подобного. Поэтому если мы имеем некий объект типа файла, кучи и так далее, с которым можно производить ряд операций, то сами боги велели на уровне реализации приписать эти операции данному объекту, то есть создать класс. Невиртуальные методы класса отличаются от обычных процедур только тем, что в них автоматически передается скрытый параметр — указатель на соответствующий объект. Теперь посмотри на API‐функции какого‐нибудь объекта, например, кучи: во все RtlHeapXXX первым параметром передается hHeap — указатель на объект. Ну и чем это отличается от ООП ? Только тем, что этот параметр прописан в API явным образом. Из этого вовсе не следует, что все RtlHeapXXX на уровне исходников реализованы в виде отдельных процедур, это запросто могут быть stdcall‐методы класса HHEAP. Вывод: на уровне машинного кода никакой разницы между процедурами и невиртуальными stdcall‐методами классов нет, но на уровне исходников классы, естественно, удобнее.

@mismatch:
mismatch

infoq.com — если вы все еще пишете на ООП языке, но поглядываете в сторону ФП, морщась при упоминании монад и аппликативных функторов, этот доклад для вас.

@Hawat:
Hawat

Как научиться мыслить по ООП-шному? Пытался и в Ruby и в Python понять эту хрень и каждый раз приходил к выводу: "А нахрена оно вообще надо, я все функциями уже накатал". В lua худо-бедно понял концепцию объекта как массива с данными и функциями, но это ведь только одна небольшая часть ООП(которая в контексте lua вообще не ООП). В общем может есть литература на русском по этому вопросу или какие-нибудь бложики?

@mismatch:
mismatch

smashcompany.com — оооччень длинная статья о сильных и слабых сторонах ООП, о том, что SOLID решает проблемы характерные только для ООП. При этом автор выбирает слабые стороны ОО языков программирования и приговаривает как хороши Clojure и Erlang. Статья полна интересных цитат и ссылочек.

@OCTAGRAM:
OCTAGRAM

octagram.name
Есть такая книга, Saba Zamir, «Handbook of Object Technology», в моей квартире толще неё, наверное, только БСЭ, там обо всём помаленьку. Нравится мне тем, что в этой книге нашлось места и для Ada, и для SOM, и для Object Pascal, и ещё много чего, о чём я не знал, но, может быть, найду время почитать.

Для своей эпохи довольно важная, каждый, кто хотел иметь отношение к объектным технологиям, стремился в эту книгу попасть (Saba Zamir там в роли редактора, а у каждой главы свой автор). Полное оглавление можно посмотреть здесь и даже купить отдельную главу за $20. Многие главы после публикации в книге были переопубликованы в Интернете, такие главы я надёргал отдельными файлами. Например, много, где лежит PDF «An Overview of the C++ Programming Language» под авторством Ricardo Devis, Bjarne Stroustrup, и там в самом начале написано «From The Handbook of Object Technology (Editor: Saba Zamir). CRC Press LLC, Boca Raton. 1999. ISBN 0-8493-3135-8» — как раз из этой книги. А какие–то главы, которые были мне особо интересны, я надёргал в Google Books: books.google.ru
Делать это получалось с переменным успехом, Google показывает не все страницы, но для разных IP скрыты разные, причём, я года два назад трёх провайдеров поменял, и ещё с работы заглядывал, но так и не все страницы взял. Сегодня ещё раз заглянул с ещё одного места, и белые пятна в интересных мне главах практически ликвидировал. Одна страница с парой–тройкой элементов списка литературы осталась скрытой. Переживём как–нибудь без списка литературы, я этой литературы всё равно накачал изрядно, читать — не перечитать.

Интересовал меня раздел V Object Technology Standards and Distributed Objects, а в нём главы с 28ой по 32ую. Там и про CORBA, и про SOM, и про DSOM; а самая последняя глава — про COM. Там я вроде тоже всё знаю, но на всякий случай выдернул и её тоже. Другой интересный раздел был посвящён ООП в разных языках программирования. То, что касается Ada 95, выдернул почти всё, ещё на всякий случай Modula-3, SmallTalk, Objective-C, но там с пробелами. Про Object Pascal я и так всё знал, поэтому даже не выдёргивал. Если в Google Books много страниц посмотреть, он начинает прятать всё большими кусками, так что когда пролистал то, что мне интересно больше всего, остальное оказывается скрыто. Физически книга есть у меня дома ( octagram.name ), если что–то ценное, могу так почитать или отсканировать.

До сих пор загадка, как это IBM так сдулись, и их технологии вычеркнулись отовсюду, как в «Черновике» Лукьяненко или как в Потерянной комнате. Своим физическим присутствием книга работает как свидетельство. Собственно описание SOM там гораздо проще, чем остальное, что я читал по этой теме.

@OCTAGRAM:
OCTAGRAM

ru.wikipedia.org
Выложил всё, что мне известно про языки программирования, с которыми был хоть как–то связан SOM. Оказывается если посчитать, их целых 8.

@Strephil:
Strephil

И быдлокод, который я переписываю, это как бы ооп-программа, с кучей типов, унаследованных от одного главного. Но написано на C, и там как сделано, просто куча, куча, куча кода, который дублируется из файла в файл, из файла в файл.
Но это я трогать не буду, оставлю, как есть.

@OCTAGRAM:
OCTAGRAM

drive.google.com
Копия: octagram.name (21 Мб)
Приложение к книге: octagram.name

Теперь можно нормально читать «Putting Metaclasses to Work: A New Dimension in Object-Oriented Programming» by Ira R. Forman, Scott H. Danforth.
Martin Iturbide сделал OCR и собрал всё в PDF. Размер уже вменяемый, но состояние ещё сыроватое. Страницы не повёрнуты, чёрный цвет букв выглядит серым и прочие недостатки, которые, наверное, не критичны.
Если есть умельцы, которые хотят и могут сделать лучше, можно скачать 400 dpi сканы здесь: octagram.name (900Mb) Я думаю, Мартин в будущем ещё улучшит качество сам.

Меня потом будет интересовать, как отправить эту книгу в 100500 либрусеков, чтоб везде была

@OCTAGRAM:
OCTAGRAM

octagram.name

24 апреля 2007 года некто Guido van Rossum оставил комментарий к книге «Putting Metaclasses to Work»:

Too bad this is out of print; I keep referring to it as the best tutorial I know for the difficult subject of cooperative multiple inheritance, supported by Python via the super() function.
amazon.com

Книга изначально стоила $39.95. Б/у книги обычно дешевеют, но эту книгу я был счастлив найти б/у за $51, потому что цена на б/у обычно не меньше $80. По моему мнению, если б/у книга дороже новой, когда новая была в печати, это признак, что надо допечатывать новые тиражи. При всём при этом книгу так и не удалось найти в p2p. С книгой, наконец, случилось то, что и должно было. Она отсканирована (первая ссылка), но ничего, кроме этого пока не сделано, и когда будет сделано, не знаю. Я вообще раньше никогда не переводил книги в цифру.

Размеров бояться не надо. Если обложка весит в цвете 23Мб, то типичная страница в оттенках серого получается на 2-4, редко 6Мб. В сумме 1Гб. Разрешение 400dpi. К книге по–хорошему должен был прилагаться CD-ROM или Floppy, но кто–то очень умный решил вместо этого разместить вложение в Интернете. Вложение упомянуто, например, на странице xiii (временный адрес octagram.name ). Как это обычно бывает в таких случаях, фиг там уже что скачаешь. awl.com теперь перенаправляет на сайт нового владельца: informit.com

На сайте написано «Register your product to gain access to bonus material or receive a coupon.», но ничего там в личном кабинете, конечно, не появилось после регистрации, а техподдержка пишет:

Dear Ivan,

If you have registered the textbook but are unable to locate the desired resources, then those resources may no longer exist.

Because this book is 16 years old and out of print since 2001, many of its resources are no longer supported and available online.

We apologize for any difficulty or inconvenience this has caused you.

Основательно поколдовав с Internet Wayback Machine, файлик получилось найти и сохранить: octagram.name

@OCTAGRAM:
OCTAGRAM

Есть одна такая книга по программированию: «Putting Metaclasses to Work by Ira R. Forman, Scott Danforth, Addison-Wesley 1999».
Её в последнее время чаще всего упоминают в контексте реализации метаклассов, а также в контексте произхождения Python, в котором метаклассы реализовывались по этой книжке. Так, например, в статье в Wikipedia про метаклассы en.wikipedia.org (в руской Wikipedia аналогично) эта книга — первая в сносках, а последующие — про метаклассы в Python, идеи для которого были взяты из неё же:

python-history.blogspot.ru
I was inspired to implement new-style classes by a very specific book, "Putting Metaclasses to Work" by Ira Forman and Scott Danforth
books.google.ru

В книге описываются возможности метаклассов на примере модифицированного C++, который их поддерживает. Этот язык не вымышленный, под него были компиляторы. Ira (Айра) R. Forman имеет прямое отношение к разработке IBM SOMObjects DTK 3.0, частью которой предполагалось сделать технологию D2SOM (DTS, Direct-to-SOM) — когда компилятор, например, C++, способен напрямую компилировать код для C++ в объекты SOM, сам создаёт файлы .idl. Технологию так и не доработали, и в SOM 3.0 она так и не вошла, а потом у IBM началась череда странностей, в результате которой и OS/2 ушла, а вместе с ней и куча технологий, для которых она была плацдармом. И у Apple с Copland не заладилось, надо же было так совпасть. В принципе, если DTS хочется посмотреть, в компиляторах для OS/2 она есть и, может быть, даже в VisualAge C++ 3.5.6 для Windows тоже, у меня этой версии нет, не проверял.

При всём обилии ссылок на эту книгу найти её в электронном виде в Greylink DC++ p2p или хотя бы из Google Books по страничке надёргивать с разных IP, как это было с «Saba Zamir: Handbook of object technology», не получилось. Её, похоже, нет в сети вообще. Она вышла из печати, а те магазины, где она ещё есть, радуют ценниками в 90 долларов. Не могу сказать, что это проблема книги, скорее проблема нашей айтишной индустрии. Когда кажется, что с новыми мощностями железа мы с удвоенной скоростью помчимся к новым достижениям, случается фазовый переход, и вместо прогресса получается одурение, прогресс вроде бы не нужен, если вот прямо сейчас можно поставить несколько временных костылей, и вся эта мощь начинает тратиться на костыли, а то, что можно было бы переписать и улучшить, так и застывает, вроде бы и не надо ничего менять, и так работает. Нет ничего более постоянного, чем временное. Вот и с технологией программирования так же. Всё то, что я написал, мало, кому известно, а чего–то лучше и не создано. Всё как–то застыло.

На этой неделе я наконец–то получил эту книгу.

@RA:
RA

Как называется метод который в абстрактном классе определён и содержит код, но который обязательно нужно переопределить в потомке?
Это точно не абстрактный метод, потому что он содержит код. А нужен он для того чтобы в потомках можно было вызвать этот "дефолтный" метод при необходимости.
(ЯП не имеет значения)

@qnikst:
qnikst

Итог предыдущих постов, про семейства типов и классы.

В ООП можно сделать открытый класс с базовой реализацией, тогда потомки типа могут переопределить реализацию метода. Близкий вариант в haskell это
сделать дефолтную реализацию внутри typeclass-а. Т.е. тут паритет (почти, если интерсно, то продолжу об этом случае отдельно).

Но у меня оказалась чуть более сложная задача, мне нужно иметь метод, возвращающий тип данных, который можно перегрузить, т.е.

type family FooT a
class Foo a where foo :: a -> FooT a

вопрос, как в хацкиле сделать? (похоже что вменяемыми методами не реально), и как сделать в ООП (прочей парадигме):

Перевод с птичьего языка:

мне хочется иметь метод:

<FooT a> foo(a)

где `FooT a` это функция из типов в типы, и если для указанного типа, решение FooT a неизвестно, то, чтобы подставлялось `a`, а имплементация foo == `id` (отображениие элемента самого в себя).

Принимаются идеи на любом ЯП, но все должно быть решено в compile time. Доп ограничения на простраство типов вводить можно.

@13oz:
13oz

Кстати, жуец. Я все забываю попросить порекомендовать мне годную книгу на тему введения в объектно-ориентированное программирование. Банду четырех не предлагать - она уже в списке на чтение.

@skobkin-ru:
skobkin-ru

LsObject — мой любимый класс:
abstract class LsObject {

}

@13oz:
13oz

Объекты создаются с помощью инстанцирования класса. Инстанцирования, блять!! Убейте переводчика

@Strephil:
Strephil

Лабаю быдлокод на асме, и вдруг мне захотелось всяким там наследований, полиморфизмов и пр.
может быть, перебыдлокодить на ц с крестами?

@OCTAGRAM:
OCTAGRAM

octagram.name
Вот это я понимаю, нормальная цена для книги. Жалко, на доставке погорю

@OCTAGRAM:
OCTAGRAM

Долгое время не могу найти в электронном виде Saba Zamir, Handbook of Object Technology crcnetbase.com

В p2p мне известны две магнитные ссылки: magnet:?xt=urn:tree:tiger:5LT56SKGOL2H2LGSGIGVRWVJUEH2D22LYRVDZHQ&xl=19198295&dn=CRC+Press+-+Handbook+of+Object+Technology.zip magnet:?xt=urn:tree:tiger:MMXI5TP5YA2FTWAD4UUA6MQUPC4XPPK3R3I5SFY&xl=18029159&dn=Handbook+of+Object+Technology+(CRC+Press).7z

Обе стоят на закачке который месяц. Нет никого с этими файлами. В поле зрения dc.proisk.org юзеры с такими файлами попадали в начале 2012го года и при мне эти юзеры на хабах так и не появлялись. sci-hub.org не помог. В инете рабочих ссылок не нашёл. При том, что находятся интересные листинги с варезом:
groups.google.com
Очень много в Интернете всяких непонятных лабиринтов типа g5q.ru , где в конце концов попадаешь на поисковик по рапидшарам, но на рапидшаре все ссылки сдохли, либо лабиринтов типа rusbook.net , где в конце концов попадаешь на сайт продавца за много $$$, но перед этим будет обман из ключевых слов Скачать книгу Handbook of Object Technology (Saba Zamir) можно в следующих форматах: rtf.zip, txt, txt.zip, fb2.zip, epub, html.zip, a4.pdf, a6.pdf, java, doc.prc.zip, rb, lit, mobi.prc, lrf, isilo3.pdb.

У меня такое чувство, что я чего–то не улавливаю. У кого–то есть гигантские коллекции книг по программированию и, такое впечатление, ещё и налаженная сеть по распространению этого дела, а в Интернет и DC++ это выплывает по воле случая. Где б надыбать библиотеку программиста, не хуже, чем здесь: groups.google.com Ну и желательно, конечно, с той книжечкой, которую я ищу.

@Zert:
Zert

А расскажите мне, уважаемые доны, в чём суть «разделения языков» на фэпэ, оопэ, дэпэ и подобные аббревиатуры? Кому-нибудь из вас в жизни реально пригодилось осознание того, что он пишет на так называемом функциональном/обжектно-ориентированном/декларативном и т.п. языке? В чём смысл разделения? Вот я пишу на Erlang, там «клёвые процессы» и сообщения, ну да, он типа считается ФП, но мне от этого факта ни холодно, ни жарко. Захотел писать на Go, там тоже процессы, каналы, но он «не считается» ФП. Как-то тоже параллельно. Писал на ссях, петоне, «хвашкиле», скалке, лишпе, никогда не задумывался, ООП это или ФП, или ещё какая ересь. В чём суть подобной классификации? Зачем «адепты ФП срутся с адептами ООП»? Хуй его знает.

@NokitaKaze:
NokitaKaze

habrahabr.ru 

@ak:
ak

А вы знаете, что травматика в законе об оружии называется "огнестрельное оружие ограниченного поражение" сокр. ОООП. Напоминает, что-то? И тем и тем можно выстрелить себе в ногу =]

@ReadMe:
ReadMe

помню что засыпал размышляя о красном развратном кубе написанном на пхп с использованием ООП...

@OCTAGRAM:
OCTAGRAM

habrahabr.ru
IBM SOM: внешняя объектная система с поддержкой наследования

// Статья стала пропуском на хабрахабр, от кого, не понятно, но и так сойдёт.

@ReadMe:
ReadMe

опять не могу сосредоточится. путаюсь в собственныз классах и методах.

@OCTAGRAM:
OCTAGRAM

iis.sinica.edu.tw

Несколько кратких документов о SOM, которые, как мне показалось, неплохо обрисовывают, чем является SOM, что такое метаклассы, несовместимость метаклассов, бинарная совместимость.
Спойлер:
1) Чувак в курсе про CLOS, ObjVLisp, SmallTalk и т. д.
2) В третьем документе презанятная табличка, сравнивающая SOM с другими средствами обеспечения бинарной совместимости между разными релизами. Оказывается, под SGI IRIX есть некий SGI Delta C++, который тоже много, чего умеет

Конечная цель этих инструментов — сделать так, чтобы любые изменения не требующие изменения исходных кодов, не требовали перекомпиляции. То есть, если использовали библиотеку одной версии, и был в ней класс, от которого мы отнаследовались, а в следующей версии этот класс изменился сам и поменял цепочку наследования, SOM или Delta C++ должны избавлять от необходимости перекомпиляции зависимого кода

@hohoho:
hohoho

есть ли тут гуру в плюсах? имеется вопрос, был бы благодарен за ответ.
в делфи есть такой механизм, как message методы, позволяющий избавиться от длинных case в оконной функции окна и транслировать сообщение по его номеру в соответствующий метод.
Более подробно (если есть желание) можно почитать тут например delphikingdom.ru

Если вкратце, то это можно обозначить таким кодом:

TSomeClass = class
private
procedure WMMessage(var Message: TMessage); message CONST_NUMBER;
protected
procedure DefaultHandler(var Message); override;
procedure HandlerProc(var Message: TMessage);
end;

{ TSomeClass }

procedure TSomeClass.WMMessage(var Message: TMessage);
begin
{код обработки}
Message.Result := 0;
end;

procedure TSomeClass.HandlerProc(var Message: TMessage);
begin
Dispatch(Message);
end;

procedure TSomeClass.DefaultHandler(var Message);
begin
with TMessage(Message) do
Result := DefWindowProc(Handle, Msg, WParam, LParam)
end;

Вызов Dispatch с сообщением под номером CONST_NUMBER приведет меня в метод WMMessage. Если соответствующего метода нет, то сообщение отправляется в DefaultHandler, где скармливается стандартной оконной процедуре.
Этот приём можно использовать не только для работы с винапи и я его активно использую в SDK плагинов для QIP — на делфях я сваял обертку, позволяющую работать с сдк более удобным способом.

Собственно, вопрос: можно ли похожую схему сделать компактно на сях, не таская за собой кучу зависимостей? Я в курсе только про существование карты сообщений в MFC и WTL. Есть ли что-то еще?
Рецоменд плиз.

@folex:
folex

Жуйк, а не посоветуешь книгу/статью по ООП? Именно по ООП, волнует терминология и все такое.
В принципе, не особо важно, какой там будет язык, но C# предпочтительнее.

@molny:
molny

Правду сказал один человек: "ООП — погремушка академиков и переучившихся студентов."

@NEKT:
NEKT

Идеальная разработка с точки зрения ООП
blogerator.ru

@zhu:
zhu

фанатики ООП сбежались и раскудахтались: оооопэээ, дооооо, кококококо habrahabr.ru доооо! пекарь! пекарь! абстракции! полиморфизм! кокококо.

@asvil:
asvil

ООП говно, всё верно. habrahabr.ru

@SLX:
SLX

Вообще не знаком с ООП( ну так, в кратце ). Что стоит почитать? Пишу преимущественно на python(django).

@kb:
kb

Осознал наконец-то аналогию между переопределением методов при наследовании в ООП и dynamic scoping'ом переменных.