OberonCore

Благодарю уважаемых adimetrius и Ивана Денисова за ответы.
Позволю себе задать вам еще один вопрос - в ваших примерах фигурируют абстрактные процедуры (как я понял из ответа adimetrius). Чуть выше я приводил пример Stores.Store, который реализован как абстрактный тип, но не содержит абстрактных процедур. Возможно ли его было определить как EXTENSIBLE без ущерба функциональности ?

Формально возможно, но это бессмысленно. Store - это основа элементов хранения; никаких полезных данных она не несет. Именно поэтому (в моем понимании) авторы запретили создавать переменные этого типа.

И тут я вспоминаю про начало этой ветки. Там тоже обсуждались формально допустимые, но бессмыссленные (бесполезные) выражения языка. Мне больше нравится подход, что такие бесполезные выражения языка стоит запретить. Их появление в программе означает (или может означать), что программист ожидает чего-то осмысленного - ведь от программиста мы ожидаем осмысленных действий, а не бессмысленных. А если он ожидает осмысленного, а его выражение - бессмысленно, полезный компилятор должен ему сообщить об этом. Но мнения разделились. В другой ветке Comdiv перечислял еще средство языка, которые запрещены по бессмысленности: кажется, проверка трюизма IS - когда заведомо известен результат.

Благодарю вас за ответ. Хотя в одном я с вами не согласен: насчет отсутствия полезных данных - не всегда необходимо расширять абстрактную запись при наследовании и аллокации. Или я не так понимаю значение ваших слов об отсутствии полезных данных.

Кажется, я не говорил, что всегда. В случае Stores.Store - там нет полезных данных. А если вы создаете свой тип, который и сам по себе несет полезные данные - тогда делайте его не ABSTRACT, а EXTENSIBLE. Кому надо - будет пользоваться прямо вашим типом, а кому нужно еще дополнить - расширит, уточнит и дополнит ).

Вообще, все эти слова - про намерение автора. Если я не пишу EXTENSIBLE после процедуры, значит, я решил, что расширителям типа не следует доопределять эту процедуру. Это мой высокоуровневый замысел. Язык дает средства его выразить, а компилятор - гарантировать.

А вообще, как я понимаю, ABSTRACT подходит:

* для формулирования "чистых интерфейсов" в мейнстримном понимании: т.е. когда у записи нет полей (по крайней мере, закрытых), а только типовые процедуры. В ББ редко встречается. TextModels.Model, например, но он расширяет Stores.Store, а там кое-что реализовано.

* либо для создания частично реализованных типов; в этом случае обычно у записи есть закрытые поля, реализованные типовые процедуры и/или модульные процедуры, которые этими закрытыми полями манипулируют. Strores.Store, Containers.View. Сторонники крайней чистоты могут сказать, что тут того и гляди хрупкий базовый класс разобьется... ну, может, но пока вроде цел )

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

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

И небольшое уточнение терминологии:
Говорить 'наследование' в тех случаях, когда создается экземпляр записи, не внося новых полей или процедур, или переопределяя процедуры базового типа или определяя абстрактные процедуры абстрактного типа, и говорить 'расширение' в остальных случаях?

я считаю, говорить «расширение» во всех случаях. незачем вводить два термина для одного и того же действия. в конце-концов, расширение — это же не только добавление полей, но и добавление/изменение функциональности.

(я иногда использую слово «уточнение» для случая, когда реализуется абстрактный интерфейс, но оно тоже, в принципе, лишнее и не очень удачное. просто привык. хотя полагаю, что отдельное слово тут всё-таки нужно.)

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

И кстати понятия "экземпляр записи" тоже нет в СЯ. Есть понятие переменной записного типа и "создать переменную":
"If p is a variable of type P = POINTER TO T, a call of the predeclared procedure NEW(p) (see 10.3) allocates a variable of type T in free storage. "

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

Удачность термина "расширение" тоже под вопросом. То, что происходит в ООП-наследовании, в общем случае не является расширением. Не исключено, что исходный термин "extension" лишён этого недостатка. По крайней мере, одним из возможных переводов является слово "продолжение", что по смыслу лучше подходит соответствующему понятию в языке программирования, чем "расширение".

Только не понятия, а термина.

Я же сказал всего лишь, что наталкивает... Это очень необязывающе.

Мне больше всего нравится уточнение. Потому что, в общем случае, к инвариантам базового типа добавляются инварианты уточняющего, конъюнктивно добавляются, я полагаю.

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

Я не знаток истории КП, но возникает вопрос "зачем в язык добавили extensible записи, поломав совместимость с Обероном". Этот модификатор не несёт особой смысловой нагрузки по месту нахождения, он лишь информирует, что, возможно, где неизвестно, поведение записи может измениться. А может и не измениться. С точки зрения ООП не сильно полезная информация. Тогда как модификатор ABSTRACT извещает нас о семантике конкретной записи/процедуры, о том, что её инвариант не реализован и поведение недоопределено. То есть это, по-сути, интерфейс или заготовка, которую нужно "допилить" перед использованием. В некоторых языкак, в том числе в Активном Обероне, у абстрактных процедур может быть реализация по умолчанию.А, например, модификатор final сообщает об изменении семантики (также конкретного типа/процедуры) - их поведение фиксировано. Пометка изменения семантики именно в месте изменения очень важна для понимания происходящего и соответствует общей тенденции. Кроме того, abstract/final точнее передают смысл объектной модели и дают гарантии на уровне компилятора, что программист не забудет доопределить тип записи и поведение процедуры или наоборот, не изменит фиксированное поведение. Поэтому, я думаю, что именно подобные соображения привели разработчиков к изменению языка кп. На это также намекают изменения в каркасе бб. Но эти изменения не были завершены, так как требовали революционных изменений, а необходимость поддержки коммерческих клиентов вынуждала двигаться мелкими шажками. А пото. проект потерял комерческую ценность и всё остановилось.
,

Благодарю вас за подробный ответ.

кстати, да. тогда «уточнение» обретает ещё больший смысл (хотя и ломает «устоявшуюся терминологию»).

Но почему не "наследсвенность"? Впрочем, с генетикой аналогия тоже так себе, не лучше, чем с правом.