Ответ на »сообщение 4591« (Сергей Перовский)
___________________________

А уж насколько изящно это можно отобразить в конкретном языке, это вопрос второстипенный.
А как сочетается данное высказывание с другим Вашим высказыванием: Для меня использование для ООП языка без явной синтаксической поддержки понятия класса НЕУДОБНО. Надо ли понимать, что это неудобство носит для Вас второстепенный характер?

Ответ на »сообщение 4572« (AVC)
___________________________

В любой книге Вирта по Оберону расширяемые записи появляются в разделе, связанным с ООП.
Это просто факт. :)

Ну не писать же ему в учебнике на 200 с. трактат о различных интерпретациях ООП в перспективе исторической, синтаксической, семантической ... есть другие специалисты ;))

Ответ на »сообщение 4569« (Посторонний В)
___________________________

Ответ на »сообщение 4567« (info21)
___________________________

Мысль эта станет похожа на важную, только при подходящем определении "индустрии".

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

Точка зрения личная, но предмет суждения -- общий. Иначе зачем ее высказывать?

Под индустрией понимается IT-индустрия. Из того, что отдельные ее представители в лице конкретных компаний интересуются и используют Оберон, не следует, что Обероном занимается индустрия. Если старик Ромуальдыч что-то там понюхал и аж заколдобился, не означает, что заколдобилось все человечество. Для этого надо усиленное внимание лидеров рынка, на худой конец влиятельных групп, позволяющее говорить о некоей масштабности применения.

Ну и логика :))
С такой аналогией про Ромуальдыча можно про что угодно сказать, что индустрия ентим не занимается.

Отождествлять индустрию с лидерами -- простите, слишком уж того ...

А про то, что Оберон не доминирует -- так мы знаем. Потому и барахтаемся. Только зачем интерпретировать этот факт так уж ... абстрактно. (Вспомнилась статья раннего Гегеля "Кто мыслит абстрактно".)

Сущность ООП
1) "расслоение" функциональности записей/объектов на *независимые* "слои".
2) возможность подставлять значение производного типа на место переменной типа-предка.
----------
Поддержка в языке, конечно, архиважна, иначе -- раз уж разрешили подставлять много чего куда-то -- такое начинается...

Ответ на »сообщение 4591« (Сергей Перовский)
___________________________

Ответ на »сообщение 4590« (AVC)
___________________________
>>>Можно сказать, что идея ООП вообще не относится к области ЯП.
+1
... А уж насколько изящно это можно отобразить в конкретном языке, это вопрос второстипенный.


То же самое можно сказать про что угодно -- про структуры управления, про процедуры, про записи...

Ответ на »сообщение 4590« (AVC)
___________________________
>>>Можно сказать, что идея ООП вообще не относится к области ЯП.
+1
Пожалуй идею ООП хорошо выражают две противоречащие друг другу и, тем не менее справедливые фразы:
1)Все люди одинаковы.
2)Нет двух одинаковых людей.
Системный анализ ориентирован в основном на выяснение того, в каком смысле рассматриваемые объекты одинаковы и в каком смысле уникальны. Построение эффективной классификации на основании наиболее значимых признаков дает мощную базу для ООП.
А уж насколько изящно это можно отобразить в конкретном языке, это вопрос второстипенный.

Ответ на »сообщение 4586« (Посторонний В)
___________________________

Ответ на »сообщение 4585« (AVC)
___________________________

Прежде чем ломать копья, хотелось бы все-таки уразуметь, в чем именно Вы со мной не согласны?

См. »сообщение 4565« и »сообщение 4572«. Я говорю, что type extension в языке Оберон само по себе, а ООП - частный случай. Вы: а чего тогда у Вирта они рядом? Я пояснил, чего они там. Где, как и почему. Спора вроде и нет, если понятно.

Никто не спорит, что область применения type extension шире, чем ООП.
Прежде всего, type extension закрыло брешь записей с вариантами, чем помогло обеспечить герметичность системы типов и облегчило создание сборщика мусора.
Другие примения расширения типа, на мой взгляд, вряд ли могут быть противопоставлены ООП.
1) Т.н. "негомогенные" структуры данных, в которых записи могут вообще не иметь процедурных полей.
Во-первых, здесь вызывает сомнение сам термин. Почему эти структуры "негомогенные"? Слово "ген" говорит о происхождении, а элементы "негомогенных" структур данных явно имеют общее происхождение, т.к. в конце концов расширяют один и тот же родительский тип.
Во-вторых, IMHO, это никак не противоречит тому, что я сказал в »сообщение 4562« и »сообщение 4564«.
2) Т.н. "шина" (software bus) -- очень мощный механизм расширения, но ее применение основано как раз на ООП (вариант с обработчиком, который применяется практически во всех графических ОС, только не так элегантно, как в Обероне). В определенном смысле, "шина" есть частный случай т.н. "двойной диспетчеризации".
Возможно, Вы под ООП понимаете общепринятый вариант с классами, как в Си++.
А я исхожу из общей (и, возможно, довольно размытой :) ) идеи, что ООП есть способ манипулировать объектами, чей окончательный тип заранее неизвестен.
Можно сказать, что идея ООП вообще не относится к области ЯП.
В принципе, я (пока) не вижу причины для спора. :)

Ответ на »сообщение 4587« (Сергей Перовский)
___________________________

Ответ на »сообщение 4584« (Посторонний В)
___________________________
Для меня использование для ООП языка без явной синтаксической поддержки понятия класса НЕУДОБНО.
К слову... Сейчас пишу мелкую программульку на Яве.
Так вот, насколько ж неудобно работать на языке без явной синт. поддержке понятия модуля! (При этом юмор в том, что код с КП на Яву может быть транслирован достаточно быстро (неспороста есть куча общих реализаций) - правда, на Яве он будет гораздо менее эффективен, из-за отсутствия read-only полей и введения get-методов, полной динамики и т.п.) Но при этом модуль Оберона должен быть оттранслирован в зависимости от ситуации то в класс, то в пакет - но в основном в класс, т.к. пакет не имеет состояния и поведения, т.е. не может играть роль полноценного модуля. В итоге понятие класса в языке дико перегружено - класс это всё и вся... Я не представляю, как можно удержать в голове для большого проекта все эти семантические оттенки - где класс это тип данных, где - модуль, где - просто контейнер для процедур... Естественно, что в итоге полная путаница, и никто за этой семантикой уже не следит. Получается, что мышление идет не на концептуальном, а на комбинаторном уровне - важна не содержательная роль элемента в системе, а только то, как и с чем его можно слепить....
Типичный пример - класс Thread - это и заготовка для пользовательских потоков, и одновременно "модуль", имеющий статические методы ("процедуры"), отвечающие за управление этими потоками... Понятие "Поток" отвечает за запуск и управление конкретными своими экземплярами... По смыслу бред полный, но за этим, видимо, в Яве уже давно никто не следит - важно только то, как это в итоге скомбинируется в коде для достижения искомого полезного эффекта...
"Когда я придумал ООП, я не имел в виду Яву" - так бы сказал Алан Кей, видимо...

Ответ на »сообщение 4587« (Сергей Перовский)
___________________________

Для меня использование для ООП языка без явной синтаксической поддержки понятия класса НЕУДОБНО.

Вы эту фразу столько раз повторяли, что ничего нового в ней нет. Ну неудобно и какие проблемы? Вам требуется наличие слова CLASS, слова OBJECT? Если мы о синтаксисе толкуем, а не о семантике? Может быть, именно Вам будет удобен Active Oberon. Там слово OBJECT узаконено. И методы внутри записи, а не сбоку болтаются. Прямо как у взрослых.

Ответ на »сообщение 4584« (Посторонний В)
___________________________
Я не могу взять в толк, о чем эта горячая дискуссия.
О том, что переиздавая книгу, Вирт в основном занимался перенесением примеров в другой язык? Иначе он и назвал бы книгу по другому и не говорил бы о переиздании.
О том, что Вирт вообще прохладно относится к ООП, считая его скорее маркетинговым слоганом, чем реальной технологией? Он в прямую это говорил в своих лекциях.
О том, что можно трактовать ООП, как частный случай расширяемых типов? Так никто и не возражает.
Когда мы говорим о качестве языка программирования, мы оцениваем не только( и не столько) возможность решения тех или иных задач - в принципе на любом языке можно решить любую задачу. В основном речь идет об УДОБСТВЕ выражения в языке структур данных и алгоритмов для решения определенных задач.
Тут не подходит математический взгляд - чем более общая теория, тем лучше.
Язык программирования представляет собой компромис между синтаксической компактностью и удобством выражения (если хотите удобством мышления).
Для меня использование для ООП языка без явной синтаксической поддержки понятия класса НЕУДОБНО. Мне приходилось писать ОО программы на Паскале, я понимаю, что весь механизм ООП можно эмулировать практически на любом языке, вопрос только об удобстве мышления и выражения мыслей.