OberonCore :: - Интерфейс модуля

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

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

Иван Кузьмицкий писал(а):

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

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

Код:

MODULE ModA;
TYPE
  P* = POINTER TO T;
  T = RECORD
    x*, y: INTEGER;
  END;
END ModA.

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

Код:

DEFINITION ModA;
TYPE
  P = POINTER TO T;
END ModA.

Более того, данный пример не имеет под собой реальной основы, что в данном случае имее особое значение. Ведь нормальный человек не станет давать своим переменным идентификаторы вида "dfgdsgd". А такое объявление

Код:

... POINTER TO ComplexDegree;

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

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

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

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

Потому что с такими полями можно работать через метапрограммирование.

Вот вам и "герметичная система типов" :о)))

Автор:	PGR [ Понедельник, 19 Март, 2007 14:38 ]
Заголовок сообщения:	Интерфейс модуля
Имеем такой модуль Код: MODULE ModA; TYPE P* = POINTER TO T; T = RECORD x, y: INTEGER; END; END ModA. При этом к полю x по указателю типа P можно обратиться из другого модуля, хотя в интерфейсе ModA этого x вообще нет: Код:* DEFINITION ModA; TYPE P = POINTER TO T; END ModA. А если так, то x появляется Код: MODULE ModA; TYPE P* = POINTER TO RECORD x, y: INTEGER; END; END ModA. Код:* DEFINITION ModA; TYPE P = POINTER TO RECORD x: INTEGER END; END ModA. Наверное, в первом случае было бы лучше выдавать такой же интерфейс, как и во втором. Все равно тип T недоступен и нет смысла показывать его в интерфейсе.

Автор:	Илья Ермаков [ Понедельник, 19 Март, 2007 23:26 ]
Заголовок сообщения:
В некотором смысле да. Но тут такая политика, как и, к примеру, в файловой системе Линукса. Если доступа к каталогу верхнего уровня нет, но знаем прямой путь до каталога, к которому доступ есть, то можем обратиться...

Автор:	PGR [ Вторник, 20 Март, 2007 00:38 ]
Заголовок сообщения:
С видимостью типа T понятно. Но в первом случае поле x экспортируется модулем, а в интерфейсе этого не видно.

Автор:	Илья Ермаков [ Вторник, 20 Март, 2007 01:29 ]
Заголовок сообщения:
Ну да, есть противоречивость в логике браузера... Тут есть неоднозначности в трактовке того, что и как показывать. На уровне фактического доступа всегда все нормально - доступ есть только к экспортированным сущностям. Например, моя процедура получит входным параметром расширение некоторого типа, которое неэкспортировано. Но если у него есть поля с меткой экспорта, то через модуль Meta я смогу их считывать/записывать...

Автор:	Иван Кузьмицкий [ Понедельник, 08 Октябрь, 2007 09:11 ]
Заголовок сообщения:	Re:
Илья Ермаков писал(а): Ну да, есть противоречивость в логике браузера... Тут есть неоднозначности в трактовке того, что и как показывать. На уровне фактического доступа всегда все нормально - доступ есть только к экспортированным сущностям. ...skip... А я вот только что наткнулся на такую штуку - экспортированная процедура с сигнатурой (h: ViewHook) в Definition вообще не показывается. Easter egg какой-то

OberonCore https://forum.oberoncore.ru/

Интерфейс модуля https://forum.oberoncore.ru/viewtopic.php?f=1&t=413	Страница 1 из 3

Автор:	Александр Ильин [ Понедельник, 08 Октябрь, 2007 09:38 ]
Заголовок сообщения:	Re: Re:
Иван Кузьмицкий писал(а): А я вот только что наткнулся на такую штуку - экспортированная процедура с сигнатурой (h: ViewHook) в Definition вообще не показывается. Easter egg какой-то В документации это описано.

Автор:	PGR [ Пятница, 12 Октябрь, 2007 12:01 ]
Заголовок сообщения:	Re: Интерфейс модуля
PGR писал(а): Имеем такой модуль Код: MODULE ModA; TYPE P* = POINTER TO T; T = RECORD x, y: INTEGER; END; END ModA. При этом к полю x по указателю типа P можно обратиться из другого модуля, хотя в интерфейсе ModA этого x вообще нет: Код:* DEFINITION ModA; TYPE P = POINTER TO T; END ModA. Наверное, поэтому в Обероне и нельзя разделить модуль на 2 отдельных файла, как в Модуле: интерфейс и реализацию...

Автор:	Илья Ермаков [ Пятница, 12 Октябрь, 2007 12:12 ]
Заголовок сообщения:	Re: Интерфейс модуля
Почему "нельзя"? Просто это файл интерфейса генерируется автоматически, компилятором (sym-файл). И открыть его в Блэкбоксе можно для просмотра.

Автор:	PGR [ Пятница, 12 Октябрь, 2007 22:50 ]
Заголовок сообщения:	Re: Интерфейс модуля
Да, генерируется автоматически и не содержит полной информации об экпортированных объектах модуля. Как написать полный текстовый DEFINITION MODULE для приведённого модуля реализации? По-моему, возможность экспортировать поля записи без экспорта самого типа записи делает это невозможным.

Автор:	Илья Ермаков [ Суббота, 13 Октябрь, 2007 00:12 ]
Заголовок сообщения:	Re: Интерфейс модуля
Полную информацию он содержит - иначе в Вашем примере компилятор не пропустил бы обращение к полю x через указатель (т.к. для компилятор IMPORT - это значит подключение именно символьного файла). Любой тип, косвенно задействованный в интерфейсе, автоматически включается в описание этого интерфейса. Но поскольку непосредственно он недоступен, то браузер его не показывает (настроен на показ только полностью экспортированных элементов).

Автор:	PGR [ Суббота, 13 Октябрь, 2007 01:35 ]
Заголовок сообщения:	Re: Интерфейс модуля
Неясно написал В смысле сгенерированное по sym-файлу текстовое представление не содержит полной информации, сам же sym-файл конечно содержит.

Автор:	Valery Solovey [ Воскресенье, 14 Октябрь, 2007 00:18 ]
Заголовок сообщения:	Re: Интерфейс модуля
Насчёт неполноты информации в данном конкретном случае можно и поспорить. Добавление в сгенерированный текст типа T не представляется возможным, так как человек, читающий текст, решит, что тип экспортируется. А на самом деле это не так. Более того, данный пример не имеет под собой реальной основы, что в данном случае имее особое значение. Ведь нормальный человек не станет давать своим переменным идентификаторы вида "dfgdsgd". А такое объявление Код: ... POINTER TO ComplexDegree; уже даёт представление о том, с чем нам придётся иметь дело. К тому же, в реальном примере будут ещё и экспортированные процедуры, принимающие в качестве параметра данный указатель, связанные процедуры. Это даст всю необходимую информацию для работы с типом. Вот и выходит, что сам тип и не нужен, да и скрыт он не для того, что бы усложнить жизнь программисту, а для того, чтобы её облегчить. Если после всего этого всё-таки потребуется иметь сам тип, то стоит подумать о целесообразности дальнейшего использования данного модуля. Ведь, это значит, что тип надо обрабатывать вручную, так как в модуле для этого не хватает инструментов. Соответственно, нет особой надобности в модуле, не избавившем от заявленной сложности. Но возвращаясь к утверждению, что модуль не разделяется на интерфейс и реализацию, хочу заметить: раз не отвергается существование sym-файла и наличия в нём экспорта модуля, "таки" придётся признать, что интерфейс и реализация разделены : ).

Автор:	PGR [ Воскресенье, 14 Октябрь, 2007 01:24 ]
Заголовок сообщения:	Re: Интерфейс модуля
Valery Solovey писал(а): Более того, данный пример не имеет под собой реальной основы, что в данном случае имее особое значение. Ведь нормальный человек не станет давать своим переменным идентификаторы вида "dfgdsgd". А такое объявление Код: ... POINTER TO ComplexDegree; уже даёт представление о том, с чем нам придётся иметь дело. К тому же, в реальном примере будут ещё и экспортированные процедуры, принимающие в качестве параметра данный указатель, связанные процедуры. Это даст всю необходимую информацию для работы с типом. Вот и выходит, что сам тип и не нужен, да и скрыт он не для того, что бы усложнить жизнь программисту, а для того, чтобы её облегчить. Но из всех этих процедур для работы с объектами данного типа мы не сможем узнать, чть оказывается можно обратиться к полю "x" такого объекта. Valery Solovey писал(а): Если после всего этого всё-таки потребуется иметь сам тип, то стоит подумать о целесообразности дальнейшего использования данного модуля. Ведь, это значит, что тип надо обрабатывать вручную, так как в модуле для этого не хватает инструментов. Соответственно, нет особой надобности в модуле, не избавившем от заявленной сложности. Интересно, зачем тогда в Оберон введена возможность создавать скрытые типы с открытыми полями?

Автор:	Илья Ермаков [ Воскресенье, 14 Октябрь, 2007 03:02 ]
Заголовок сообщения:	Re: Интерфейс модуля
Потому что с такими полями можно работать через метапрограммирование. Положим, вашей процедуре передали какую-то запись. Вам глубоко параллельно, что это за запись, где она объявлена, и экспортирована ли сама. Но вы получите доступ к тем её полям, которые помечены как экспортированные. Т.е. экспорта на всю запись нет - никто за пределами модуля не может использовать сам тип (т.е. объявлять его экземпляры), но работать с разрешёнными полями тех экземпляров, которые гуляют по системе от модуля-владельца - можно.

Автор:	Илья Ермаков [ Воскресенье, 14 Октябрь, 2007 10:46 ]
Заголовок сообщения:	Re: Интерфейс модуля
Нет. У каждого элемента есть метка экспорта, т.е. разрешение или запрет доступа снаружи модуля (в том числе через метапрограммирование, если используется высокоуровневый интерфейс Meta, а не низкоуровневый Kernel, через который возможно всё). Я выше уже приводил пример - в Юниксе, если на папку нет доступа, но есть доступ на файл, то зная полный путь, к этому файлу можно обратиться. Так и тут.

Страница 1 из 3	Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/

Автор:	Geniepro [ Воскресенье, 14 Октябрь, 2007 09:07 ]
Заголовок сообщения:	Re: Интерфейс модуля
Илья Ермаков писал(а): Потому что с такими полями можно работать через метапрограммирование. Положим, вашей процедуре передали какую-то запись. Вам глубоко параллельно, что это за запись, где она объявлена, и экспортирована ли сама. Но вы получите доступ к тем её полям, которые помечены как экспортированные. Т.е. экспорта на всю запись нет - никто за пределами модуля не может использовать сам тип (т.е. объявлять его экземпляры), но работать с разрешёнными полями тех экземпляров, которые гуляют по системе от модуля-владельца - можно. А не нарушает ли это "герметичность" системы типов?

Автор:	Евгений Темиргалеев [ Воскресенье, 14 Октябрь, 2007 19:08 ]
Заголовок сообщения:	Re: Интерфейс модуля
От себя хочу добавить такой момент. В документации модуля Integers: Код: TYPE Integer = POINTER; Однако, если посмотреть интерфейс модуля, получим: Код: Integer = POINTER TO IntegerDesc; где IntegerDesc - не экспортированный тип. Можно предположить, что швейцарцы сами до конца не определились с тем, что и как тут делать.

Автор:	AVC [ Понедельник, 15 Октябрь, 2007 01:27 ]
Заголовок сообщения:	Re: Интерфейс модуля
Geniepro писал(а): Вот вам и "герметичная система типов" :о))) А где здесь нарушается герметичность? Герметичность в том, что к переменной (не прибегая к loop-holes) можно обратиться только в соответствии с ее типом. Где именно это свойство не соблюдается?