На базарной площади довольно часто можно слышать высказывания об
Обероне. Мне кажется, что на базарной площади пора появиться ветке об
этой системе и языке, что-то вроде "Мысли об Обероне". Что это такое, перспективы
этой системы, что
полезного можно извлечь из него для программирования на Дельфи
(например) и др.
Ivan
Всего в теме 4531 сообщение
Ссылки по теме "Оберон" и "Компонентный паскаль"
Отслеживать это обсуждение
- Free Pascal, Oberon, BlackBox
- Разработка препроцессора gpre для delphi\freepascal.
- Component Pascal и среда разработки BlackBox
- FreePascal: реальная альтернатива или OpenSource — блажь?
№ 3731 13-12-2005 08:54 | |
Ответ на »сообщение 3729« (Сергей Губанов)
___________________________
2) Модуль может не содержать процедур:
В принципе это можно свести к public-полю объекта. А вот то, что модуль может просто экспортировать типы, уже поинтереснее в качестве иллюстрации.
№ 3730 13-12-2005 08:46 | |
Ответ на »сообщение 3728« (Сергей Губанов)
___________________________
Вся компиляция идет по очереди. Так что не понятно что значит компилировать вместе???
Теоретически это вполне возможно. Другое дело, что я не знаю, где это вообще применялось (возможно, в каких-то Ada-системах и делали).
В случае Оберона сначала определяется зависимость модулей по импорту (тут общий импорт в модуле, без разделения на DEFINITION-импорт и IMPLEMENTATION-импорт), затем вычленяются наборы модулей (в соответствии с топологической сортировкой), по степени зависимости друг от друга (сначала те, которые ни от кого не зависят, затем те, кто от них и так далее). Вот их компиляцию теоретически и можно распараллелить. Но можно для Оберона пойти по другому пути, сведя задачу к Modula-2 за счет первичного выделения интерфейсов (см. дальше).
В Modula-2 (где DEFINITION отделен от IMPLEMENTATION и есть два импорта), напр., можно было бы сначала оттранслировать DEFINITION-модули (стандартным последовательным образом, опять-таки с учетом топологической сортировки), а затем использовать полученный набор SYM-файлов (результат трансляции DEFINITION-модулей) для параллельной компиляции IMPLEMENTATION-модулей (здесь порядок уже вообще не важен).
При этом стоит учесть, что некоторые системы программирования для Modula-2 обходятся без генерирования SYM-файлов (формируя их на лету и храня в памяти). Так что на второй фазе требуется лишь доступа к общей памяти при параллельной компиляции других модулей.
№ 3729 13-12-2005 08:27 | |
Ответ на »сообщение 3724« (al_mt)
Можно ли в рамках нашего диалога считать, что модуль - это такой объект (экземпляр класса), который содержит только методы и не может "размножаться"?
1) Модуль - не экземпляр чего-то. Каждый модуль уникален.
2) Модуль может не содержать процедур:
MODULE X;
VAR a*: INTEGER;
END X.
А почему Вы этого не знаете?
№ 3728 13-12-2005 08:22 | |
Ответ на »сообщение 3726« (al_mt)
Я, всего навсего, хочу сказать, что по моему мнению, компилировать разные программные модули можно и вместе
Непонятно, компилировать вместе это как?
Пусть модуль Б импортирует модуль А. Для того чтобы скомпилировать модуль Б нужно иметь исходный текст модуля Б и (символьный) бинарный файл модуля А, который можно получить только скомпилировав модуль А. Для компиляции модуля Б исходный текст модуля А не нужен.
То есть сначала кто-то где-то компилирует модуль А. Потом он даёт нам его символьный бинарный файл. Затем мы у себя компилируем модуль Б, не имея исходного текста модуля А.
Вся компиляция идет по очереди. Так что не понятно что значит компилировать вместе???
№ 3727 13-12-2005 08:14 | |
Ответ на »сообщение 3724« (al_mt)
___________________________
Можно ли в рамках нашего диалога считать, что модуль - это такой объект (экземпляр класса), который содержит только методы и не может "размножаться"?
Боже, как все запущено! Ну да модуль -- это такой уродец-класс, у которого поотрезали все на свете, запретили размножаться и оставили инвалиду только методы-костыли, которые ничего не могут вызывать в других классах. Примите наши соболезнования.
Выберите время и почитайте про модульное программирование. А еще лучше -- изучите каноническую Modula-2. Глядишь, польза будет.
№ 3726 13-12-2005 07:01 | |
Ответ на »сообщение 3725« (Владимир Лось)
___________________________
В приведённом определении сказано "программный модуль программируется, компилируется и отлаживается отдельно от других модулей". Я, всего навсего, хочу сказать, что по моему мнению, компилировать разные программные модули можно и вместе, они от этого не становятся одним и не перестают быть программными модулями :)
Относительно модуль vs. ООП - я говорю об идеологии. Модуль может содержать ООП, а объектный класс можно собрать из отдельных модулей. Т.е. идея в том, что модульное программирование не отрицает ООП и точно так же ООП не отрицает модульного программирования.
Другое дело, что здесь зашла речь "Модули - без ООП!" с намёком, что без ООП-то лучче :)
№ 3725 13-12-2005 06:47 | |
Ответ на »сообщение 3720« (al_mt)
___________________________
Я бы сказал, что раздельная компиляция не обязательна
Пардон, разрешите поинтересоваться, мы о программировании компонентов?...
И как следствие не вижу ни малейшего противоречия между модульным и ОО программированием.
В рамках ЧЕГО? На каком уровне представления системы? На коком этапе её развития, как проекта?
№ 3724 13-12-2005 06:43 | |
Ответ на »сообщение 3721« (Руслан Богатырев)
___________________________
Можно ли в рамках нашего диалога считать, что модуль - это такой объект (экземпляр класса), который содержит только методы и не может "размножаться"?
№ 3723 13-12-2005 06:39 | |
Ответ на »сообщение 3721« (Руслан Богатырев)
___________________________
Ага. Кажется понял.
Вы хотите сказать, что если есть модуль, который на самом деле - объект (класс?), то возможность унаследоваться от него является источником ошибок, которых не может возникнуть в случае классического модульного программирования?
P.S. ...полиморфизм пока отложим
№ 3722 13-12-2005 06:38 | |
Ответ на »сообщение 3718« (Сергей Губанов)
___________________________
Кстати, а откуда взялся термин "кошачий пастух"?
http://www.books.ru/shop/books/309225
Спасибо.
Мне вот это в аннотации очень понравилось:
Программист подобен кошке, которая гуляет сама по себе. Так уж исторически сложилось.
Что-то мне подсказывает, что книга посвящена организации работ в программировании "информационно-справочных систем", "электронных бирж", "удалённого образования", "электронных столов заказов и корзин в магазине", или "автоматизации бизнес-процессов и бухгалтерского учёта"...
Умаляю, исправьте меня, если я ошибаюсь! :о)
Отслеживать это обсуждение
Дополнительная навигация: |
|