OberonCore

Коллеги, быть может, этот вопрос где-то уже и обсуждался, но я не нашёл.

В процессе работы над Ofront'ом+ я столкнулся с такой особенностью поведения BlackBox при копировании расширяемых записей: копирование невозможно для записи, помеченной любым атрибутом, и не только для потомка записи, но и для нерасширенной записи того же типа. В то же время, компилятор вполне может отследить статически, а рантайм в процессе исполнения программы, является ли запись потомком или же она не расширена, а объявлена с тем же типом. Я нахожу эту невозможность копирования очень странной. И намерен смягчить эту стратегию в Ofront'е+ для записей, чей тип является гарантированно не расширенным, хотя запись и помечена как расширяемая.

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

Вот код, который отвечает за такую проверку (OPB.CheckAssign):

BlackBox:

Ofront+:

Если я убираю вот это самое IF x = y THEN, то перестаёт компилироваться, например, ZlibDeflate из ETH Oberon, т.к. переменые типа запись StaticTree становятся несовместимы сами с собой.

Непонятно. Вы хотите разрешить копирование расширенных записей или только того же типа? Если второе, появится ещё один источник ошибок времени исполнения.

Я хочу разрешить копирование записей одного типа, объявленных как EXTENSIBLE. Копирование между предком и потомком записи этим кодом пресекается.

А как быть с указателями?

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

Я, так или иначе, должен был столкнуться с этой проблемой, т.к. я стыкую Оберон-2 и КП. И появилась сущность "запись, которую нельзя расширить" наряду с "записью, которую можно". И получается, что все записи Оберона-2 становятся расширяемыми, других там просто нет. И код на Обероне-2, который копирует записи в общем-то одного типа, перестаёт компилироваться просто из-за привнесённой КП-шной интерпретации расширяемой записи с невозможностью её потом копировать. Типа: если вам нужно копировать запись, просто не делайте её расширяемой. Но сейчас в Ofront'е+ перед копированием типы проверяются на полное соответствие, никакого смешивания наследников и предков не допускается. А указатели-поля записи при копировании просто дублируются. Были NIL - остались NIL. Были не NIL, таковыми и будут.

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

А Вы отследите ситуацию, если потомок StaticTreeChild передается как параметр процедуры, например VAR c: StaticTree? А нужно присвоить c := stree

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



Согласен с тем, что хорошо бы снабдить такую рантайм-проверку информацией о месте в коде, где сработала охрана типа. Это собираюсь сделать.