На базарной площади довольно часто можно слышать высказывания об
Обероне. Мне кажется, что на базарной площади пора появиться ветке об
этой системе и языке, что-то вроде "Мысли об Обероне". Что это такое, перспективы
этой системы, что
полезного можно извлечь из него для программирования на Дельфи
(например) и др.
Ivan
Всего в теме 4531 сообщение
Ссылки по теме "Оберон" и "Компонентный паскаль"
Отслеживать это обсуждение
- Free Pascal, Oberon, BlackBox
- Разработка препроцессора gpre для delphi\freepascal.
- Component Pascal и среда разработки BlackBox
- FreePascal: реальная альтернатива или OpenSource — блажь?
№ 3811 15-12-2005 08:51 | |
Ответ на »сообщение 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?
№ 3810 15-12-2005 08:39 | |
Ответ на »сообщение 3805« (Сергей Губанов)
___________________________
Придется различать два понятия модуля: единица компиляции и единица загрузки.
В win32 среде это существенно разные вещи. Хотя никто не мешает в том же ОП вместо unit, всегда писать library и осуществлять динамическое связывание. Вот только никто так не делает. Почему? Зачем нужен компоновщик?
Компоновщик может проверить целостность проекта. Там, где кончается его поле деятельности начинается многократно описанный "ад dll".
Мне лично удобнее самому делить проект на единицы загрузки, а их в свою очередь на единицы компиляции.
Автоматизация поиска нестыковок в раздельно загружаемых модулях, это замечательно, но очень хочется иметь компоновщик.
№ 3809 15-12-2005 08:36 | |
Ответ на »сообщение 3806« (Руслан Богатырев)
Что означает фраза "интерфейс изменился"? Если я поменяю порядок объявления (махну местами строчки) экспортируемых констант, он изменится? Что считается существенным в изменении, а что несущественным (т.е. на основании чего компилятор принимает решение, что "не поменялся"?)
Вы как будто сами не знаете! Символьный файл - это таблица символов для компилятора. Ему всё равно в каком порядке у Вас строчки написаны. Например, браузер интерфейса отображает интерфейс модуля упорядочив имена по алфавиту.
Ну, а то что существенно, а что не существенно уже давно описано у того же Regis Crelier в его диссертации. Не понятно что Вы тут пытаетесь сейчас наизобретать нового.
№ 3808 15-12-2005 08:33 | |
Ответ на »сообщение 3806« (Руслан Богатырев)
___________________________
Ответ на »сообщение 3805« (Сергей Губанов)
___________________________
Что означает фраза "интерфейс изменился"? Если я поменяю порядок объявления (махну местами строчки) экспортируемых констант, он изменится? Что считается существенным в изменении, а что несущественным (т.е. на основании чего компилятор принимает решение, что "не поменялся"?)
Перестановка экспортируемых констант местами -- интерфейса не меняет. (Как и перестановка слагаемых -- сумму. :))
А вот изменение значения константы -- меняет.
Если я изменю константу и перекомпилирую модуль, то при попытке его загрузки получу ошибку ("inconsistency").
№ 3807 15-12-2005 08:21 | |
Ответ на »сообщение 3803« (Руслан Богатырев)
___________________________
А вы поясните, не поленитесь. Мы же рассуждаем, анализируем, разбираемся, а не ищем ответ на конкретный вопрос.
К тому же поправочка на ветер: интересует не язык Компонентный Паскаль в реализации BlackBox, а подходы к этому в языках Оберон, Оберон-2 и КП.
Чтобы детально разобраться, надо в коде покопаться. :)
А подход, ИМХО, кратко изложен в "Compiler construction".
Требуется обеспечить согласованность (? - consistency) использования модуля (как при компиляции, так и при загрузке) и его интерфейса.
Рассматривается несколько вариантов.
Пометить символьный файл датой и временем создания, например. Но такой подход имеет недостаток - метки символьных файлов будут разными, если один и тот же модуль компилировать в разное время.
Следовательно, надо обеспечить зависимость меток (отпечатков - fingerprints) только от самих элементов интерфейса.
Если fingerprints привязывать к отдельным элементам интерфейса модуля, можно добиться того, чтобы при расширении (а не только сохранении) интерфейса не требовалось перекомпилировать модули-клиенты.
№ 3806 15-12-2005 08:19 | |
Ответ на »сообщение 3805« (Сергей Губанов)
___________________________
Попробую ужать вашу цитату до сути:
1. Когда вы компилируете модуль первый раз, генерируется новый символьный файл.
2. Если интерфейс изменился, компилятор пишет новый символьный файл и указывает в рабочем журнале, какие изменения появились по сравнению со старой версией.
Что означает фраза "интерфейс изменился"? Если я поменяю порядок объявления (махну местами строчки) экспортируемых констант, он изменится? Что считается существенным в изменении, а что несущественным (т.е. на основании чего компилятор принимает решение, что "не поменялся"?)
№ 3805 15-12-2005 07:53 | |
Ответ на »сообщение 3803« (Руслан Богатырев)
А вы поясните, не поленитесь.
Процитирую
Перед тем, как модуль использовать, его необходимо загрузить с диска в оперативную память. Но перед тем, как он может быть загружен, его необходимо откомпилировать (команда Разработка -> Компилировать). Компилируя модуль, компилятор порождает кодовый файл и символьный файл. Кодовый файл содержит исполняемый код, который может быть загружен в память. Кодовый файл есть разновидность суперлегкой DLL (динамически загружаемой библиотеки). Компилятор также производит символьный файл, который содержит бинарное представление интерфейса модуля. Если модуль импортирует другие модули, компилятор читает символьные файлы этих модулей, чтобы проверить, что их интерфейсы используются корректно. Процесс компиляции можно изобразить так:
<картинку смотрите в Блэкбоксе>
Когда вы компилируете модуль первый раз, генерируется новый символьный файл. В рабочем журнале компилятор пишет примерно следующее:
компилируется "ObxPhoneDB"
new symbol file 564 640
Первые два числа показывают, что машинный код в новом кодовом файле имеет длину 564 байта.
Второе число показывает, что модуль содержит 640 байт глобальных переменных (пять входов в переменной db; каждый вход состоит из двух строк по 32 элемента в каждой; каждый элемент имеет 2-байтный Юникод-символ). Если символьный файл точно для такого интерфейса уже существует, компилятор выдает более короткое сообщение:
компилируется "ObxPhoneDB" 564 640
Если интерфейс изменился, компилятор пишет новый символьный файл и указывает в рабочем журнале, какие изменения появились по сравнению со старой версией. Например, если вы только что изменили процедуру LookupByNumber, компилятор пишет:
компилируется "ObxPhoneDB"
LookupByNumber is new in symbol file 964 640
Символьный файл используется только во время компиляции, он не используется во время выполнения. Чтобы загрузить модуль, достаточно его кодового файла. Модули загружаются динамически, т.е. нет отдельного шага линкования, как в большинстве статических языков.
№ 3804 15-12-2005 07:48 | |
Ответ на »сообщение 3794« (Takun)
Дык это... Если отбросить расширение типа (и рассматривать Оберон как чисто модульный язык), то в нем не поддерживается программирование от интерфейса (модуля). Я не могу задать интерфейс, а затем проверять реализации на соответствие ему.
Как сказать...
MODULE Interface;
TYPE
T1* = PROCEDURE(a: INTEGER): INTEGER;
VAR
do1-: T1;
PROCEDURE Init* (d1: T1);
BEGIN
ASSERT(d1 # NIL, 20);
ASSERT(do1 = NIL, 21);
do1 := d1
END Init;
END Interface.
MODULE Implementation;
IMPORT Interface;
PROCEDURE Do1 (a: INTEGER): INTEGER;
BEGIN RETURN a + 1
END Do1;
BEGIN
Interface.Init(Do1)
END Implementation.
№ 3803 15-12-2005 07:39 | |
Ответ на »сообщение 3802« (Сергей Губанов)
___________________________
Провокационный вопрос для знатоков.
Я работаю с модулем. Транслирую.
В хелпе к Блэкбоксу всё это описано.
Компонентное ПО, Часть 1,
глава 3 Приёмы проектирования,
раздел 3.2 Модули и подсистемы.
А вы поясните, не поленитесь. Мы же рассуждаем, анализируем, разбираемся, а не ищем ответ на конкретный вопрос.
К тому же поправочка на ветер: интересует не язык Компонентный Паскаль в реализации BlackBox, а подходы к этому в языках Оберон, Оберон-2 и КП.
Но если знаете только про связку КП/BlackBox, все равно поясните. Не так много места займет.
№ 3802 15-12-2005 07:32 | |
Ответ на »сообщение 3799« (Руслан Богатырев)
___________________________
Провокационный вопрос для знатоков.
Я работаю с модулем. Транслирую.
В хелпе к Блэкбоксу всё это описано.
Компонентное ПО, Часть 1,
глава 3 Приёмы проектирования,
раздел 3.2 Модули и подсистемы.
Отслеживать это обсуждение
Дополнительная навигация: |
|