OberonCore

Кажется, я придумал, как создавать абстрактные объекты в Oberon-2 (ключевое слово ABSTRACT в КП). Это несколько более трудоёмко, и нет поддержки времени компиляции, но добиться рантайм-поддержки можно.

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

Так реализованный признак абстрактности можно по желанию сохранять в наследнике.

Аналогично можно реализовать объект с атрибутом LIMITED. Для этого достаточно метод Abstract (можно назвать его Limited) не экспортировать, и перекрывать только во внутренних, не экспортированных расширениях. Извне перекрыть его будет невозможно, и чужие расширения будут приводить в действие "сигнализацию" при попытке использования такого объекта.

Надо ещё подумать про экспорт "только для реализации", пустые методы и признак EXTENSIBLE. Сейчас времени нет, убегаю.

Разве пустые это не просто

Нашёл нестыковку в документации Docu/CP-New.odc:

Да, точно. Я имел в виду абстрактные методы.

Экспорт "только для реализации" в Oberon-2 сделать не получится.

EXTENSIBLE - таковы все записи в Oberon-2.

"Final" - не расширяемая запись. Скорее всего, не получится реализовать.

Абстрактный метод - это метод с телом, состоящим из единственного вызова HALT.

ABSTRACT - имеющий в реализации всех методов обязательный вызов абстрактного экспортированного метода Abstract.

LIMITED - аналогично ABSTRACT, но метод Abstract не экспортирован.

Получается, что абстрактные записи обязательно должны иметь методы, при вызове которых сработает сигнализация. А как быть с записями, которые состоят только из данных? Зачем их делать абстрактными? Чтобы гарантировать корректную инициализацию перед использованием (представьте, что все данные скрыты, не экспортированы). В этом случае использующие процедуры (которые фактически являются методами, хоть и не объявлены таковыми текстуально) должны контролировать инициализированность записи. Ведь если просто сделать NEW() или объявить запись локальной переменной, то в ней будет мусор, и использовать до инициализации её нельзя. Особенно остро вопрос стоит для компилятора XDS, который иногда забывает занулить указатели в стековом объекте. Решением будет создание метода Init, который будет приводить новый объект в корректное состояние, и одновременно запоминать указатель на объект в скрытом поле "self" самого объекта. При использовании объекта достаточно проверить совпадение адреса объекта с содержимым поля "self". Конечно, есть некоторый шанс, что случайным мусором в памяти как раз на месте поля self окажется как раз адрес объекта. Понизить шанс такого совпадения можно использованием более длинной структуры данных и помещения в неё некого хэша от адреса объекта. А всё для чего? Ради того, чтобы программист не забыл вызвать метод Init.

Самое неприятное во всём этом - то, что обнаружится неправильность реализации только во время выполнения, а значит, в непредсказуемый момент времени, и проследить проблему до источника может оказаться не просто.

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

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