OberonCore

Сам я ООП еще не знаю. Попытался поискать информацию об ООП в Обероне, везде рассказывается об отличиях со стандартным взглядом (классы, объекты), а так что бы с «нуля» не нашел. Получается, что бы понять ООП в Обероне нужно сначала изучить его в каком-нибудь промышленном языке…
Возникают следующие вопросы:В
озможно, я плохо искал, и уже есть учебники (книги, статьи) по КП в которых раскрывается ООП?
Интересны: сам материал по ООП, а так же показательные примеры, где ООП востребовано.

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

В чем суть Оберона я уже сформулировала: модуль + расширение RECORD-типа. А динамика загрузки-выгрузки - побочная вещь.

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

Тони Хоар, один из ближайших друзей и соратников Вирта, называл это концептуальной экономией (conceptual economy). И наряду с надежностью и эффективностью считал очень важным свойством языка программирования.


Готов выслушать Вашу формулировку Оберон-технологии.

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

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

Если позволите, я бы это прокомментировала. В основе ООП лежит концепция класса. Откуда возникло это слово и сама идея? Разумеется, Smalltalk не был тут первопроходцем. Первым языком, в котором слово class, обозначающее ту концепцию, которая близка нашему нынешнему понимаю ООП, была Simula 67. Здесь Снегурочка с Вами готова согласиться. Но дело в том, что идея класса была сформулирована и реализована несколько раньше - в языке Simula I. Там уже были activity (классы) и process (объекты). Кристен Нигаард и Оле-Йохан Дал еще тогда заложили идею порождения объектов, каждый из которых суть данные плюс связанные с ними операции, правда, тогда еще без наследования.

В 1965 г. в ALGOL Bulletin вышла важнейшная работа Тони Хоара, которая называлась просто "Record Handling". В ней Хоар обобщил опыт других языков и предложил идею record class, объединив запись - record (известной по PL/I и COBOL) со ссылкой - reference (она была предложена Виртом в 1965 г. в его первом языке Euler и двумя годами ранее в языке CPL из английского Кембриджа).

Как признавались Нигаард и Дал в своих воспоминаниях о создании Симулы, именно осенью 1966 г. они тщательно изучали работы Хоара (вслед за первой вышла в марте 1966 г. и Further Thoughts on Record Handling). Они искали способ "прикрутить" понравившуюся идею record class к своей Симуле. И пришли к выводу, что ее можно сформулировать как process class, убрав слово process. Т.е. оставить просто class. Правда, reference там были в неявном виде.

В 1972 г. в Советском Союзе в изд-ве "Мир" вышел сборник "Языки программирования", где были опубликованы переводы докладов на Летней школе NATO по языкам программирования, которая прошла в 1966 г. в Виллар-де-Ланс (Франция). Если сможете его раздобыть, рекомендую внимательно изучить работу Хоара "Обработка записей" (Record Handling). Несмотря на не очень хороший перевод почитать очень даже стоит. Работа занимает примерно 60 страниц. Из нее понятно, откуда росли ноги ООП и что закладывалось в основу той самой Симулы-67, от которой обычно и принято вести отсчет эре ООП. В том же сборнике есть и столь же объемная статья Оле-Йохана Дала о Симуле. Сам Дал вместе с Нигаардом в качестве источника идей Симулы-67 упоминали именно эту тройку работ Хоара (включая и его доклад на школе NATO).

Второе открытие ООП связано с задачей построения оконного пользовательского интерфейса и языком Смолтолк. На этой задаче большинству студентов объясняют принципы ООП.

Собственно, это детище Алана Кея и дало реальный импульс моде на ООП, которая переросла потом во всеобщую "ООПсовизацию" программирования. Алан Кей, в отличие от большинства из нас, хорошо был знаком с ранними работами Никлауса Вирта, и с большим интересом относился, в частности, к тому же языку Euler, где была заложена динамическая типизация в рамках алголоподобного языка.

Поскольку сей факт известен очень немногим, приведу точные цитаты (дело было в апреле 1993 г. в американском Кембридже на конференции HOPL-II, сразу после доклада Вирта об истории разработки Паскаля):

Allen Kay: Your thesis and Euler were going in a pretty interesting direction. Why did you go back to more static languages?

Niklaus Wirth: For a thesis topic you have to do something that is new and original, you are expected to explore new ways. Afterwards, as an engineer, I felt the need for creating something that is pragmatic and useful.

В основу Паскаля были положены идеи Хоара о record handling. Но даже без намека на ООП. В Modula и Modula-2 вошли идеи Симулы по моделированию на основе процессов, хотя облечено это было в концепцию модуля из языка Mesa. В Обероне Вирт по сути вернулся к первоистокам: record + reference (но уже и ссылки на procedure) и дали фундамент для ООП без использования самого ООП. Круг замкнулся.

Таким образом, Оберон помимо того, что был квинтэссенцией Паскаля и Модулы, вобрал в себя идеи Хоара, Euler и Simula.



Ответ на >сообщение 1771< (AVC)
___________________________

Насчет модуля, кажется, понятно.

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

А в чем принципиальное различие между расширением типа и наследованием?

Вопрос непростой. Помимо чисто "идейно-психологического" различия (математическое понятие против социально-антропологического) есть и кое-что еще. Наследование (inheritance) устанавливает отношение наследования (нерефлективное, несимметричное, но транзитивное) между двумя сущностями - классами. Строго говоря, из наследования не вытекает, что "наследник" должен в точности сохранять структуру "наследодателя", лишь дополняя ее, и безболезненно подменять "наследодателя" везде, где тот ранее использовался.

У Вирта расширение типа (type extension) строится на понятии подтипизации (subtyping). Есть тип (расширяющий тип), есть его подтип (расширяемый тип). Принцип подстановки (Liskov substitution principle), выдвинутый Барбарой Лисков в 1993 г., говорит о том, что S является подтипом типа T, если для любого истинного q(t) следует, что истинно и q(s).

Если не ошибаюсь, в Eiffel при наследовании можно не только модифицировать, но и даже удалять свойства, унаследованные от базового класса. В C++, например, есть приватное наследование (private inheritance), нарушающее принцип подстановки и подтипизацию.

Вообще говоря, имеет смысл воспринимать type extension в Обероне с позиции record class Хоара, а не process class Нигаарда-Дала. Здесь больший уклон в данные, а не в операции. Хотя при наличии в Обероне процедурных типов, через которые и реализуются методы, никто не запрещает все перевернуть с ног на голову.
Снегурочка



Ответ на >сообщение 1856< (Сергей Перовский)
___________________________

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

А следует ли из этого, что ООП пригодно для большинства простых систем? А если нет, то почему языки полностью "погружают" в ООП, как, например, Java?

Что касается понимания областей применимости ООП на заре его появления, то не скажу за Нигаарда и Дала, которые действительно в основном работали с имитационным моделированием, но по Хоару это не совсем так (цитирую по работе Record Handling из Летней школы NATO 1966):

Фундаментальная особенность нашего понимания мира заключается в том, что мы систематизируем свой жизненный опыт, представляя его в виде отдельных понятий или объектов (столы и стулья, банковские займы и алгебраические выражения, многочлены и люди, транзисторы и треугольники и т.п.), и наше мышление, язык и действия основываются на обозначении, описании и манипуляциях с этими объектами, с каждым в отдельности или в связи с другими объектами. Если мы хотим решить задачу на компьютере, то часто нужно построить в нем модель того аспекта реального или воображаемого мира, к которому будет применяться алгоритм решения задачи. В такой модели каждый объект исследования должен быть представлен некоторой величиной, которая "доступна" программе и может быть использована ею в процессе работы. Назовем такую величину записью (record). Каждый объект, представленный в запоминающем устройстве компьютера в виде записи, будет обладать одним или более атрибутами (attributes), с которыми и приходится иметь дело при решении задачи. Обычно эти свойства выражаются простыми значениями соответствующего типа. <...>

Объекты реального мира удобно классифицировать с помощью некоторого числа взаимно исключающих классов (classes), причем каждый класс обозначается некоторым собирательным именем, таким, как "человек", "банковский заем", "выражение" и т.д. <...>

Если программа выполнялась уже в течение некоторого времени, то может случиться так, что требуется сегмент расширения, а единственные доступные сегменты находятся в опасной близости к магазинной памяти. При подобных обстоятельствах целесообразно воспользоваться процедурой автоматического собирания свободных участков памяти, подобной той, которая описана Маккарти (1960).<...>

В реальных условиях часто разбивают класс объектов на несколько взаимно исключающих подклассов (subclasses). Например, класс позвоночных можно разбить на такие подклассы, как млекопитающие, пресмыкающиеся, птицы и рыбы...
Класс записей (record class), который разбивается на подклассы, называется составным; класс или подкласс, который не является составным, называется простым. Ссылочные переменные могут, согласно их описаниям, указывать на все записи составного класса или же их область действия может быть ограничена каким-то одним определенным подклассом.<...>

Если областью действия ссылочной переменной является, согласно ее описанию, составной класс, то программист может пожелать на некотором этапе выполнения программы определить, какому из возможных подклассов фактически принадлежит запись, на которую ссылается в настоящее время эта переменная. Этого можно достигнуть с помощью специальной конструкции, называемой различитель класса записи (record-class discriminator). <...>

Расширение определения знаков операций для действий над ссылками на записи новых типов называют перегрузкой (overloading). Впервые идея перегрузки была предложена Дж.Маккарти...

Как видно из этого текста, 40 с лишним лет назад Хоар достаточно подробно описал идеи ООП, при этом ни о каком ограничении сферой имитационного моделирования речи не идет. Хоар еще указал в своей работе такие языки обработки "ООП"-записей, как Lisp, Simula I и PL/I.

Вирт в Паскале интерпретировал идеи Хоара через указатели, записи и вариантные записи. Спустя полтора десятка лет после Паскаля он пришел к выводу, что это надобно делать через type extension с запретом вариантных записей (лобовой реализации составных классов). В остальном и автоматическая сборка мусора, и наследование, и полиморфизм (без явного использования этих терминов) были Хоаром озвучены. Было это до появления Simula 67.

Экземпляр типа записи = объект

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

Есть хороший пример демонстрации возможностей графического каркаса ББ.

Если в StudKvur вместо OUT m: ARRAY OF REAL написать OUT m: ARRAY 3 OF REAL, то в StudKvurExF будет возникать ошибка: StudKvur.ReshKvUr(ar[тип не совпадает с типом формального VAR параметра],a,b,c)
Непонятно почему так нельзя…

Т.е. по большему счету это нужно для эффективности? Или есть еще какой смысл в них?

1) Вы выбрали совершенно неудачный способ передачи параметров.

Дискриминант - это часть внутренней реализации процедуры решения кв. ур-я - и его не следует выносить наружу! У вас интерфейсный код узнает, есть ли корни, по значению дискриминанта, а должен всего лишь получить TRUE/FALSE - есть ли корни или нет.

А если мы захотим изменить реализацию процедуры ReshKvUr - и будем вычислять корни, ну, к примеру, численным методом (пусть и маразм), без вычисления дискриминанта? Что возвращать в m[0] будем?

Думаю, убедил, что так нельзя.

Теперь по поводу возвращаемого значения процедуры. Ну, самое первое - если процедура имеет OUT-параметры, то возвращаемое значение ей обычно не задают. Это так называемый принцип "чистоты функций". Т.е. если пишем функцию, которую можно будет использовать в выражениях, то она не должна ничего менять ни вокруг себя, ни в своих параметрах, а только возвращать значение (как функция в математике).

А на входе процедуры ставится проверка соблюдения этих предусловий - оператор ASSERT: для вашего случая было бы - ASSERT(LEN(m) >= 3). И все. Что произойдет, если процедуре подадут неверные данные? Попробуйте - увидите, что выскочит окошко сбоя - трепа. Все правильно - нарушение предусловия процедуры - это и есть сбой, и выполнение процедуры немедленно прерывается.

Т.е. в вашем варианте вместо возврата значения надо было бы заводить еще один OUT-параметр: OUT noErrors: BOOLEAN).
Однако если мы отказались от массива, то он стал не нужен.

Кстати, а можно еще вообще не возвращать явно "есть ли корни, нет ли корней". У типа REAL есть особое значение - бесконечность, неопределенность. Записывается как INF.
Просто, если корней нет, то вернем x1=x2=INF.
А код верхнего уровня будет проверять IF x1 # INF THEN корни есть ELSE корней нет END.

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

Почитайте в Общих вопросах, там это обсуждалось.

4) По поводу указателей.
Эээ, батенька, указатели нужно изучить, без них далеко не уедешь.

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