OberonCore

в статье Руслана Богатырева http://oberon2005.ru/obe_faq1.html сказано:
"В Обероне есть три кита, на которые опирается его философия (см. "От Modula к Oberon"):

1. процедурные типы (процедура как тип, коммутация функций);
2. модули (единица компиляции и загрузки, основа построения компонентов);
3. расширение комбинированного типа (расширяемые записи, альтернатива ООП и основа динамической эволюции систем)."

в разделе документации бб "Cоглашения по написанию кода":
"Старайтесь избегать супервызовов и процедурных типов."

получается, что в один из китов Оберона в КП уже не кит совсем? %)
или как правильно интерпретировать...

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

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

Называть детали вроде процедурных переменных "китами" да еще "философии" Оберона ... не знаю, не знаю.

Но в Сообщение о языке КП дословно сказано следующее:

Справедливо ли это для других Оберонов или только для КП? То есть мне процедурные типы не кажутся устаревшими, а в оригинальном (первом) Обероне они очень неплохо помогают увидеть объект полностью, когда все его методы, так же, как и атрибуты, описываются внутри одной записи. Или я чего-то не понимаю и процедурные типы однозначно маст дай?

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

Совсем без процедурных типов плохо. (Есть такой удобный критерий: без процедурных типов трудно студентам объяснять что к чему -- все равно приходится вводить процедурные переменные.)
Другое дело, как повысить безопасность. Было предложение задвинуть процедурные типы в SYSTEM. Жизнь покажет.

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

В определении КП процедурные типы помечены на удаление в будущем (хотя часть каркаса их применяет при этом). "Задвинуть в SYSTEM" - значит официально исключить из определения языка, но оставить на уровне небезопасной системной библиотеки... которая и не библиотека совсем...
По сути SYSTEM - это тоже часть языка только неопределённая...

Тогда получается, что определение языка меняется в зависимости от наличия IMPORT SYSTEM; ??? ...
Вопросы семантики определений типов и операций со значениями этих типов - один из основных в определении языка.
Для языка со строгой типизацией (да и вообще - для остальных, не столь строгих, как Обероны) я не могу представить ситуации "выноса в SYSTEM" СПОСОБА определения конкретного типа процедурной ссылки... Откуда компилятор будет знать всё множество сигнатур процедур, которые понадобятся или на которые фантазия программиста разгуляется? :о)

Определение или нет -- все это условности.

Программист будет использовать не процедурные переменные, а объекты с методами, вот и все.

Оно и так меняется. SYSTEM - это compiler magic, по сути дела. Так же как и COM. Оба они не входят в определение языка, но, тем не менее, полностью обрабатываются компилятором.

То есть вы предлагаете, что само включение в модуль строки IMPORT SYSTEM является включением режима компиляции, при котором разрешаются конструкции определения типов ссылок на процедуры? А не проще ли (и - «традиционней») сделать это через установку флагов опций в командной строке компилятора или в модифицированных комментариях в тексте модуля? А то как-то неочевидно...

Ну дак оно и сейчес так работает, только с флагами записей/процедур/etc.
Используя SYSTEM программист явно берёт на себя ответственность за последствия. Да и система, теоретически, может следить за небезопасными модулями. Флаги в командной строке делают текст модуля несамостоятельным, заставляя полагаться на внешние условия. Спецкомментарии - ещё один "язык" внутри оберона. Оно надо?
Другое дело, что я не вижу проблем с отслеживанием всех ссылок на процедуры. Они же в принципе ничем особенным не отличаются...

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

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

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