OberonCore

Имеем такой модуль

При этом к полю x по указателю типа P можно обратиться из другого модуля,
хотя в интерфейсе ModA этого x вообще нет:


А если так, то x появляется



Наверное, в первом случае было бы лучше выдавать такой же
интерфейс, как и во втором. Все равно тип T недоступен и нет смысла
показывать его в интерфейсе.

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

С видимостью типа T понятно. Но в первом случае поле x экспортируется
модулем, а в интерфейсе этого не видно.

Ну да, есть противоречивость в логике браузера...
Тут есть неоднозначности в трактовке того, что и как показывать.
На уровне фактического доступа всегда все нормально - доступ есть только к экспортированным сущностям.
Например, моя процедура получит входным параметром расширение некоторого типа, которое неэкспортировано. Но если у него есть поля с меткой экспорта, то через модуль Meta я смогу их считывать/записывать...

А я вот только что наткнулся на такую штуку - экспортированная процедура с сигнатурой (h: ViewHook) в Definition вообще не показывается. Easter egg какой-то

В документации это описано.

Уточню для тех, кто придёт после меня: в документации к модулю DevBrowser.

Наверное, поэтому в Обероне и нельзя разделить модуль на 2 отдельных файла, как в Модуле: интерфейс и реализацию...

Почему "нельзя"? Просто это файл интерфейса генерируется автоматически, компилятором (sym-файл). И открыть его в Блэкбоксе можно для просмотра.

Да, генерируется автоматически и не содержит полной информации об экпортированных объектах модуля. Как написать полный текстовый DEFINITION MODULE для приведённого модуля реализации? По-моему, возможность экспортировать поля записи без экспорта самого типа записи делает это невозможным.

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

Неясно написал В смысле сгенерированное по sym-файлу текстовое представление не содержит полной информации, сам же sym-файл конечно содержит.

Насчёт неполноты информации в данном конкретном случае можно и поспорить. Добавление в сгенерированный текст типа T не представляется возможным, так как человек, читающий текст, решит, что тип экспортируется. А на самом деле это не так.

Более того, данный пример не имеет под собой реальной основы, что в данном случае имее особое значение. Ведь нормальный человек не станет давать своим переменным идентификаторы вида "dfgdsgd". А такое объявлениеуже даёт представление о том, с чем нам придётся иметь дело. К тому же, в реальном примере будут ещё и экспортированные процедуры, принимающие в качестве параметра данный указатель, связанные процедуры. Это даст всю необходимую информацию для работы с типом. Вот и выходит, что сам тип и не нужен, да и скрыт он не для того, что бы усложнить жизнь программисту, а для того, чтобы её облегчить.

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

Но возвращаясь к утверждению, что модуль не разделяется на интерфейс и реализацию, хочу заметить: раз не отвергается существование sym-файла и наличия в нём экспорта модуля, "таки" придётся признать, что интерфейс и реализация разделены : ).

Но из всех этих процедур для работы с объектами данного типа мы не сможем узнать, чть оказывается можно обратиться к полю "x" такого объекта.


Интересно, зачем тогда в Оберон введена возможность создавать скрытые типы с открытыми полями?

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

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

А не нарушает ли это "герметичность" системы типов?

Нет. У каждого элемента есть метка экспорта, т.е. разрешение или запрет доступа снаружи модуля (в том числе через метапрограммирование, если используется высокоуровневый интерфейс Meta, а не низкоуровневый Kernel, через который возможно всё). Я выше уже приводил пример - в Юниксе, если на папку нет доступа, но есть доступ на файл, то зная полный путь, к этому файлу можно обратиться. Так и тут.

C ними можно работать и напрямую:

Если в BlackBox такие поля вообще не показываются, то в ETH Oberon ещё хуже: они показываются, но не там

От себя хочу добавить такой момент. В документации модуля Integers:

Однако, если посмотреть интерфейс модуля, получим:
где IntegerDesc - не экспортированный тип. Можно предположить, что швейцарцы сами до конца не определились с тем, что и как тут делать.

А где здесь нарушается герметичность?
Герметичность в том, что к переменной (не прибегая к loop-holes) можно обратиться только в соответствии с ее типом.
Где именно это свойство не соблюдается?