Ответ на »сообщение 3808« (AVC)
___________________________


Перестановка экспортируемых констант местами -- интерфейса не меняет. (Как и перестановка слагаемых -- сумму. :))
А вот изменение значения константы -- меняет.


Тут есть варианты:
http://www.master.cymbeline.ch/

Definitions, posted on 27.09.2005 19:27 by Roger
Finally all the features of the meta data section are implemented in both, the object file plugin for the compiler as well as the reflection module. I also extended the decoder module to subdivide the display of the code section by using the procedures' names. So that means, that the list of procedures in the whole module also works fine.

What I started today is, that constants are being saved to the constants section in any case. This would make it possible for the compiler to not just copy the values into the new program but use a link to the values in the source module. This would mean, that changing an exported constant in a module would NOT require the modules which import that constant to be recompiled. As much as I understood from what Thomas (one of the gurus) said, they wanted or needed this for quite a long time.

Categories: Object Files, Reflection

Ответ на »сообщение 3828« (SAGE)
___________________________

Ответ на »сообщение 3824« (Cardinal)
___________________________

Зашел на http://bluebottle.ethz.ch/dlxmas04.html. Эта та самая рождественская, о которой говорили SAGE и Руслан?

Точно прошлогодняя.

В crazy-fresh есть скин xmas

Ответ на »сообщение 3825« (Руслан Богатырев)
___________________________


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

Да и в BlackBox то же, правда без опций. 

Правда, и тут вопрос: разрешается одно расширение, которое перезаписывает предыдущее? Или несколько? А могут ли клиенты привязываться к разным поколениям такого расширения интерфейса?

2-е расширение расширяет 1-е, 3-е - 2-е, ... Ветвится конечно не может.
В BlackBox'е при импорте клиент привязан только к той информации из сервера, на которую ссылается. (Насколько я понимаю в Modula явно указывается, что именно импортировать). Похоже клиенты особо не различают поколения интерфейса. Проверка происходит исключительно по наличию в интерфейсе  сервера необходимых объявлений.

Ответ на »сообщение 3824« (Cardinal)
___________________________

Зашел на http://bluebottle.ethz.ch/dlxmas04.html. Эта та самая рождественская, о которой говорили SAGE и Руслан?

Точно прошлогодняя.

Ответ на »сообщение 3786« (iZEN)
___________________________
Дядя Бертран - просто бизнесмен и не более.
Издал книгу для пропаганды своего языка-среды.
Лучше смотрите в сторону Smalltalk. Так больше пользы будет.

Ответ на »сообщение 3824« (Cardinal)
___________________________

Эта та самая рождественская, о которой говорили SAGE и Руслан?

Нет, по-моему, прошлогодняя.

Ответ на »сообщение 3822« (Takun)
___________________________

По видимому следует различать изменение интерфейса и расширение интерфейса. Если "изменение" сводится к добавлению новых типов/переменных/констант, то с точки зрения уже откомпилированных клиентских модулей интерфейс не изменится. Более того, если клиентский модуль не использует экспортируемый тип/переменную/константу, то он не чувствителен к к его исчезновению/изменению.

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

Правда, и тут вопрос: разрешается одно расширение, которое перезаписывает предыдущее? Или несколько? А могут ли клиенты привязываться к разным поколениям такого расширения интерфейса?

Зашел на http://bluebottle.ethz.ch/dlxmas04.html. Эта та самая рождественская, о которой говорили SAGE и Руслан?

Ответ на »сообщение 3820« (Сергей Перовский)
___________________________

Конечно, с точки зрения ресурсов, помодульная загрузка экономичнее. Но что будет с надежностью?

Чтобы был жесткий контроль версий бинарных модулей (бинарный -- не значит обязательно в машинном коде, просто результат трансляции), необходимо внутри них хранить идентификационные метки (timestamp/checksum, причем внутри каждого модуля эту пару для каждого импортируемого им модуля). Эти метки может построить только компоновщик.

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

А далее иметь специальный конфигуратор, который позволял бы снимать/ослаблять контроль на предмет подмены модулей на лету.

Ответ на »сообщение 3811« (Руслан Богатырев)
___________________________

Ответ на »сообщение 3809« (Сергей Губанов)
___________________________

Ну, а то что существенно, а что не существенно уже давно описано у того же Regis Crelier в его диссертации.

А вам словами это сказать трудно? Или пользователь той же системы BlackBox, чтобы это выяснить, должен читать какую-то исследовательскую работу, причем к BlackBox не имеющую прямого отношения? Я вас правильно понял?

Я хочу разобраться в методах контроля версий интерфейсов в Оберонах: даты, fingerprint, checksum и т.п. Неразумный вопрос?

Давайте пойдем по документации BlackBox. Я задал вопрос, что имелось в виду под фразой "не поменялся"? Где я могу найти на него ответ?

Теперь простой пример из Оберон-2/КП:

Вариант 1.
TYPE T = RECORD a*, b*, с-: INTEGER END;

Вариант 2.
TYPE T* = RECORD a*, b*, с-: INTEGER END;

Интерфейс поменялся или нет? А если поменялся, какой смысл имеет запись варианта 1?

По видимому следует различать изменение интерфейса и расширение интерфейса. Если "изменение" сводится к добавлению новых типов/переменных/констант, то с точки зрения уже откомпилированных клиентских модулей интерфейс не изменится. Более того, если клиентский модуль не использует экспортируемый тип/переменную/константу, то он не чувствителен к к его исчезновению/изменению.