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

Для написания ОО программ на классическом Паскале приходилось использовать вариантные записи, по сравнению с ними расширение типа практически неотличимо от полноценной синтаксической реализации ООП :)

Поймите простую вещь. Не надо зацикливаться на ООП. И если Вы видите перед глазами нечто, что может позволить что-то написать в ОО-стиле, это не значит, что оно предназначено именно для этого и должно использоваться только так.

Большая проблема мира Оберонов (точнее, тех, кто их использует) в том, что они уперлись в ООП. Да не сошелся на нем свет клином. Как Вы там любите говорить? Давайте без фанатизма. Обероны могут и умеют работать без ООП. Только вот это их преимущество практически не используется. И совершенно напрасно.

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

Почему Вирт упорно считает Record более "фундаментальным" понятием, чем Object, а не частным случаем, мне никак не понять.

Вроде бы я уже подробно тут объяснял, откуда ноги растут. Речь идет о работах Тони Хоара.

Честно говоря, сложно сейчас рыться в архивах форума. Поэтому просто дам выжимку из своей записной книжки, которая есть под рукой.


Как известно, первый препринт ETH Zurich по классическому Паскалю появился в ноябре 1970 г. Кстати, он и вышел среди прочих технических отчетов ETH за номером 1, что весьма знаменательно. Два года назад я попросил Вирта помочь его получить, но в Москве Вирт извинялся, что просьбу выполнить не удалось, и при этом выглядел несколько озадаченным. Оказалось, что в его архивах и ближайшем доступном окружении этого препринта не было. Потом его где-то раздобыли, отсканировали и выложили среди других препринтов ETH (правда, все-таки во второй редакции -- июля 1971 г.). Он доступен и на EuroProg: http://www.europrog.ru/paper/nw1970-01e.pdf

К тому моменту уже существовала система программирования Паскаля на компьютере CDC 6000 (фирмы Control Data Corp.). Вирт вообще старался придерживаться золотого инженерного правила: сначала реализовать идеи, прочувствовать их физический смысл на практике, а только потом "столбить". Компилятор (причем однопроходный) на CDC 6000 был написан на самом Паскале и реализован методом раскрутки (bootstrapping), что уже обсуждалось. Это отмечено и в препринте.

Дальше будет интересно: не поленитесь открыть этот препринт. И вы поймете, зачем я его искал (не только ради исторического интереса). На стр. 21 в пунке 6.2.5 там найдете... классы (class types), реализованные в соответствии с идеями Тони Хоара. Напомню, что, на мой взгляд, первый программный манифест ООП был озвучен Тони Хоаром в 1966 г. на Летней школе научного комитета NATO, которая прошла в Виллар-де-Ланс (Франция). Там же был Оле-Йохан Дал, который использовал выступление Хоара (и две предшествовавшие этому публикации Хоара по обработке записей) для пересмотра своей Симулы (вместе с Нигаардом).

Хоар обобщил опыт первой Симулы и ряда других языков (включая PL/I) и в докладе "Record Handling" в Виллар-де-Ланс изложил идею record class (что в несколько видоизмененном виде и под названием class вошло в Симулу-67). При этом идеи записей и их взаимосвязь со ссылками на практическом уровне детально были разобраны еще в первом языке Вирта -- Euler (1965), которым так интересовался Алан Кей (автор Smalltalk). А схема Хоара (record class) была реализована до Паскаля в виртовском языке "Algol W": см. http://www.europrog.ru/paper/nw1966-03e.pdf
и http://www.europrog.ru/paper/nw_algw.pdf

Сами же записи (record) впервые появились в языке AED-0 Дугласа Росса (кстати, основателя той самой компании SofTech, которая вошла в число 4 финалистов Ада-тендера). Он же был автором известных методологий SADT и IDEF0. Стоит вспомнить, что в начале 1970-х годов Дуглас Росс утверждал, что "80% или даже 90% информатики будет в будущем основываться на теории конечных автоматов". В AED-0 записи назывались шариками, каплями (beads). Использовалось и понятие plex (узел), которое обозначало группу записей, связанных с помощью ссылок.

Итак, Вирт в Паскале практически лоб в лоб реализовал идеи своего друга и коллеги (вот, кстати, откуда пошли вариантные записи -- от Хоара), хотя наследование (subclass) Вирта явно насторожило. Эта конструкция первого Паскаля (class type), как следует из более известного препринта ETH по пересмотренному Паскалю (ноябрь 1972 г.), из языка спустя год с небольшим была изъята (а заодно Вирт powerset переименовал в set плюс добавил упакованные записи): http://www.europrog.ru/book/panw1972e.pdf

Вирт посчитал, что просто record с указателями будет вполне достаточно и специальное слово class с дополнительной семантикой лучше не вводить. Спустя полтора десятилетия (примерно в 1986 г.) Вирт вернулся в одном из первых внутренних вариантов Оберона к корням ООП в трактовке Хоара, дополнив ее с подачи Юрга Гуткнехта конструкцией расширения типа (type extension). При этом оказался верен своему предубеждению против ООП.

В 1972 г., кстати, был опубликован второй манифест ООП: "Иерархические структуры программ" (Hierarchical Program Structures), авторами которого были Оле-Йохан Дал и Тони Хоар. Это был печатный вариант лекций Дала в Летней школе в Маркторбердорфе (Германия) в 1970 г. Его перевод на русский язык можно найти в сборнике "Структурное программирование": http://www.europrog.ru/book/spod1975r.pdf Там же был представлен механизм композиции классов, который получил название сочленения.

Выстраивается примерно такая картина.

Хоар придумал class record, т.е. записи со ссылками (не забыв упомянуть Вирта). Дал и Нигаард взяли идею Хоара (также сказав об этом) и довели в Симуле-67 до process class (или просто class), соединив универсальную структуру данных (record) с функциональностью. Т.е. предложили инкапсуляцию (не надо путать с information hiding Парнаса). Американцы в Xerox PARC ввели в язык Mesa (делался на основе Паскаля, Алгола-68 и Симулы-67 с учетом BCPL) процедурные переменные, создав основу процедурного делегирования. Вирт включил это в Modula-2, а затем оно проникло в Обероны, где базисом (помимо модулей) выступают все те же class record Хоара в виртовской интерпретации (type extension). Кстати, модули Оберона пришли из модулей Modula-2, а те, в свою очередь, из модулей Mesa. А модули Mesa делались на основе работы Парнаса (раннюю работу Наура они похоже не читали), причем за основу брали... классы Симулы-67.  :)

Одной из интересных идей Mesa был binding mechanism, т.е. динамическое связывание процедур. Ныне это называют late binding (отложенное связывание). В общем-то, процедурная коммутация на этом-то и строится.

Что касается идей применения хоаровской конструкции record в качестве основы ООП (для выражения отношений между сущностями), то в сфере искусственного интеллекта давненько в ходу были семантические сети (до первой Симулы), ну а с появлением фреймов и слотов Марвина Минского (где-то в районе 1975 г.) стало понятным (все ведущие ученые тогда варились в общем котле и активно общались друг с другом не только на конференциях), что классы-фреймы -- это сильное средство построения информационных моделей.

Надо будет выложить редкие и малоизвестные специалистам ранние работы Хоара по истокам ООП (на русском одна из них, которая была представлена на конференции NATO 1968 г., выходила в сборнике "Языки программирования" п/р Женюи, 1972). Да и стоит, наверное, облечь некоторые свои наблюдения, размышления и архивные изыскания в форму статьи о корнях и природе ООП (в трактовках Хоара, Дала, Кея), но вот все руки никак не дойдут.

Ответ на »сообщение 5112« (Руслан Богатырев)
___________________________
Хотя, что есть ООП -- точки зрения разные. Поэтому в том, что имеет отношение к ООП, а что не имеет -- каждый волен судить на свой лад.
Поэтому и не следует делать провакационных утверждений типа Расширение типа -- это не ООП. :)

В классическом Паскале (если кто еще помнит) было такое понятие -- вариантные записи (предложенные Хоаром). Нужны для динамически разнородных типов данных. Расширение типа задумывалось Виртом в том числе и для их замены на более надежное средство.
Для написания ОО программ на классическом Паскале приходилось использовать вариантные записи, по сравнению с ними расширение типа практически неотличимо от полноценной синтаксической реализации ООП :)

Весьма подробно именно этот подход к использованию механизма расширения типа (type extension), без использования полей процедурного типа для имитации методов и, тем более, без связанных процедур (type-bound procedures), введенных в Обероне-2, разобран в работе проф. Вирта, где впервые была представлена им такая концепция. Очень рекомендую внимательно с ней ознакомиться.
Вы знаете, как я уважаю Остапа Ибрагимовича :)
Но на концепцию это не тянет, тем более с сылкой на Симулу.
В Симуле класс содержал единственный метод (схему поведения), все остальное было в точности по приведенной схеме.
Почему Вирт упорно считает Record более "фундаментальным" понятием, чем Object, а не частным случаем, мне никак не понять.

В минувший четверг на странице исследовательской группы проф. Гуткнехта (Programming Languages and Runtime Systems Group, ETH Zurich) выложена новая версия реализации языка Composita с исходными текстами (включая исходники ран-тайма), а также с набором тестов производительности и парой примеров приложений. См. http://www.jg.inf.ethz.ch/wiki/ComponentLanguage/Front

Изменения по сравнению с вариантом двухмесячной давности затронули Component System (на уровне ядра и компилятора языка), а также Traffic Simulation Package и Benchmark Package.

Это весьма нешаблонный взгляд на компонентное программирование и его поддержку на уровне языковых конструкций, включая интерфейсы-контракты с поддержкой спецификаций протоколов взаимодействия. Подход Composita -- предмет пристального изучения в свете поддержки параллельного и компонентного программирования в рамках проекта новой ОС "Роса".

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

Согласен. Есть полиморфизм -- есть ООП. Расширение типа без полиморфизма есть вещь маргинальная, о которой и говорить не стоит (блох и так хватает).

В классическом Паскале (если кто еще помнит) было такое понятие -- вариантные записи (предложенные Хоаром). Нужны для динамически разнородных типов данных. Расширение типа задумывалось Виртом в том числе и для их замены на более надежное средство.

Для работы с вариантными записями, как известно, совсем не обязательно использовать ООП. Есть запись, она имеет варианты, при этом эволюционирует (расширяется другими типами). Есть процедуры работы с такими родственными типами. Они не имеют никакого отношения к классам и не являются методами. Обычные процедуры.

Весьма подробно именно этот подход к использованию механизма расширения типа (type extension), без использования полей процедурного типа для имитации методов и, тем более, без связанных процедур (type-bound procedures), введенных в Обероне-2, разобран в работе проф. Вирта, где впервые была представлена им такая концепция. Очень рекомендую внимательно с ней ознакомиться.

См. N.Wirth "Extension of Record Types" // SIGSCE Bulletin, June 1987. http://www.europrog.ru/paper/nw1987-01e.pdf

Маргинальность подобного использования -- IMHO, излишняя субъективность восприятия.

Хотя, что есть ООП -- точки зрения разные. Поэтому в том, что имеет отношение к ООП, а что не имеет -- каждый волен судить на свой лад.

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

Ответ на »сообщение 5092« (Руслан Богатырев)
___________________________
Расширение типа -- это не ООП. Это средства, которые позволяют как получать схему с ООП, так и строить свои схемы (generic bus как пример).
Поехали по двадцать пятому разу...
Расширение типа и ООП семантически эквивалентны.
(Это generic bus - то, не ООП?)


Согласен. Есть полиморфизм -- есть ООП. Расширение типа без полиморфизма есть вещь маргинальная, о которой и говорить не стоит (блох и так хватает).

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

Ответ на »сообщение 5097« (Илья Ермаков)
В "Дизайне и эволюции C++" описывается почему именно для исключений в C++ комитетом была выбрана семантика завершения (то, что ты называешь try/catch), а не семантика восстановления (то, что предлагаешь ты). Вот цитата:

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

Ответ на »сообщение 5104« (pepper)
___________________________
Ответ на »сообщение 5097« (Илья Ермаков)
Нет. Пример был обратный. Компонента записи DVD использует высокоуровневый интерфейс для получения данных для записи. Если я правильно понял твою мысль, то ты предлагаешь начиная с какого-то уровня превращать физические ошибки в программные (нарушения постусловия). Для компоненты записи DVD это означает невозможность нормально обработать какую-нибудь ошибку сети или ошибку чтения файла (в случае программной ошибки ты предлагаешь перезапускать всю систему).

В случае ошибки компонента DVD должна обратиться к верхнему уровню системы с запросом "что делать", на верхнем уровне может либо быть сделан запрос к пользователю (типа Ab,Ret,Ign...), либо попытка восстановить соединение, либо ожидание, после чего с верхнего уровня возвращается результат - что делать дальше... Например, отдаётся новый хэндл файла, либо говорится его пропустить... При этом клиент сервиса записи ничего даже не замечает, обратное обращение идёт по боковому callback...

Ответ на »сообщение 5073« (Стэн)
___________________________

Вопрос в следующем: Какой класс задач требует реальной динамической расширяемости? Т.е. те задачи, в которых нельзя остановить программу, чтобы изменить ее часть. Подавляющее большинство клиентских приложений, которые среднестатистический пользователь использует в офисе и дома прекрасно дружат с перезапуском. Состояние между сеансами сохраняется в файлах или БД.

Динамическая расширяемость, как и любой инструмент/механизм, -- палка о двух концах. У нее есть свои плюсы и минусы. Они раскрываются применительно к задачам и тем, кто их конкретно решает.

Динамическая расширяемость хороша, когда не надо останавливать работающую систему и требуется насытить/улучшить ее (в отношении функциональности, эргономики, производительности и др.). С таким же успехом можно, правда, и обеднить/ухудшить :)

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

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

Но динамика (побыстрее попробовать) нередко стимулирует недостаточно тщательное доведение компонентов/модулей. Чем-то напоминает хроническую болезнь под название "отладка", которая давно поразила многих программистов. Соблазн быстро попробовать желательно все же сдерживать. И отделять испытательную компьютерную систему от эксплуатационной.

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

Потратив два года на споры, я вынес впечатление, что можно привести убедительные логические доводы в пользу любой точки зрения. Они имелись даже в специальной работе [Goodenough, 1975] по обработке исключений. Мы оказались в положении все тех же античных философов, которые так яростно и умно спорили о природе Вселенной, что как-то забыли о ее изучении. Поэтому я просил любого, кто имел реальный опыт работы с большими системами, представить конкретные факты.

Есть очень неплохая книга (раньше все-таки умели писать), в которой этот вопрос (стратегии "уйти"-"отметить"-"разобраться") по обработке исключений разобран довольно тщательно. Там тоже используется ссылка на работу Goodenough, но люди еще умеют и сами анализировать. Речь идет о книге Стивена Янга "Real Time Languages: Design and Development" (1982) в пер. на русский она вышла в 1986 г. -- "Алгоритмические языки реального времени: конструирование и разработка". Там вполне обосновано использование только стратегии "уйти" применительно к задачам реального времени.

Книга сегодня не только не потеряла своей ценности, но стала, пожалуй, еще более актуальной. Надо будет ее выложить в EuroProg.