Попалась в сети маленькая статья. Думаю кому-то будет интересно:
http://www.itk.ru/article/oo_paul.shtml

Интересно посмотреть на этот CLU

Несогласен со многими утверждениями. Тем более, статья устарела.

Потому что .NET не рассматривается?

поподробнее пожалуйста . Меня например многие помеченные особенности зацепили.

LSD
Для начала, в Яве уже есть дженерики aka параметризованные типы aka шаблоны. Потом я совершенно не вкурил, что там аффтар писал про "сохранение доступности" и необходимость использования public-членов в Яве. Затем, меня удивило, что "в новых версиях С++ появились шаблоны...". Я думал, они были еще давным-давно . Потом еще уж слишком мягко сказано о поддержке исключений в С++. Они чрезвычайно неформализованны. К примеру, одни функции стандартной библиотеки кидают исключение, другие возвращают -1, WinAPI вообще Бог знает что возвращает. В Java/.NET это куда более формализовано. Затем, удивила фраза "типы "первого" сорта нельзя описать средствами языка (это относится и к С++)". Покажите мне язык, где самому можно написать int.

Генерики, это не шаблоны.



Как я его понял, с классами надо работать только через интерфейс, есть такие-то методы и все, никаких полей наружу не выводить. А вообще мне кажется что за идеал он считает COM, особенно вот эта фраза:

Ну просто один в один Windows Scripting.



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

Хм. А чем дженерики отличаются от шаблонов в Сцы++?

Не порождают дополнительный код, это только опция языка. Что-то типа autoinboxing, чуть удобней писать код, но ничего принципиально нового нет. Код с генериками запросто можно скомпилировать для выполнения в JVM версий младше 1.5.

[offtop]
Ладно, другой вопрос
Чем дженерики в Java отличаются от дженериков в .NET?

Цитата(LSD @ 2.3.2006, 18:49 )

Код с генериками запросто можно скомпилировать для выполнения в JVM версий младше 1.5.

Как это
[/offtop]

Я не знаком с генериками в .NET.


Борландовский компилятор это умеет. Там нет ничего такого, что требавало бы поддержки со стороны JVM.

В Java, как сказал LSD, это не более чем синтаксический сахар. В .NET дженерики напрямую поддерживаются рантаймом, и JIT создает для value-типов более эффективные специализации — без boxing/unboxing.

Хм... «Формализовано» — это, пожалуй, не совсем удачный термин в данном контексте. Никакого математического формализма за повсеместным применением исключений в Java/.NET не стоит. Просто их фреймворки навязали стиль “exceptions everywhere”, и им предпочитают пользоваться, хотя «индусам» от программирования это не помеха. Что до C++, то как раз в стандартной библиотеке используются только исключения.

Сама статья производит впечатление поверхностной. Почему-то из громадного числа ОО-языков выбраны только три, и один из них является академическим экспериментом, не дожившим до наших дней. Почему не Smalltalk или не CLOS, раз уж захотелось рассмотреть немейнстримные подходы к ООП.

А ну, попробуй обратиться к Win32Api функциям из C#? Неужто тоже выбрасывают исключения? :O
Задолбало уже ассоциирование С++ c MFC или, того хуже, Win32Api. C++ это STL и Boost.

А теперь критика статьи.

Я так полагаю аффтар немного недоучил C++. Если выделять C++ методы в .cpp файл то не надо никакой перекомпиляции.

Если вы такие умные то почему вы такие бедные? Я про этот CLU в первый раз вообще слышу, судя по тому что статья старая, он так и остался "идеальным" языком.

Аффтар не читал никогда Александреску.

---
Со всем остальным я согласен.

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


И с трехуровневой моделью тоже? По мне так это overkill во многих случаях.

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

но если это уж сильно напрягает и если никто не хочет выделять объект в стеке, то пусть выделит public-часть, а реальный объект унаследует от нее и никому снаружи модуля не показывает...

в том-то я приятность C++ - в нем много чего не встроено (как элемент языка), но это можно сделать
Добавлено @ 23:55
ну или privat-часть выделить в отдельный объект, а в основном оставить на нее указатель, это уж кому как нравится...