На базарной площади довольно часто можно слышать высказывания об
Обероне. Мне кажется, что на базарной площади пора появиться ветке об
этой системе и языке, что-то вроде "Мысли об Обероне". Что это такое, перспективы
этой системы, что
полезного можно извлечь из него для программирования на Дельфи
(например) и др.
Ivan
Всего в теме 4531 сообщение
Ссылки по теме "Оберон" и "Компонентный паскаль"
Отслеживать это обсуждение
- Free Pascal, Oberon, BlackBox
- Разработка препроцессора gpre для delphi\freepascal.
- Component Pascal и среда разработки BlackBox
- FreePascal: реальная альтернатива или OpenSource — блажь?
№ 3801 15-12-2005 06:58 | |
Ну это -- fingerprints разные...
Ага. "Отпечатки пальцев" видимо фиксируют все "прожилки" интерфейса.
А если мне важно знать дату снятия отпечатка? Или это не фиксируется? А если мне важно знать изменение порядка следования описаний (т.е. они те же, но в другом порядке)? Это контролируется. Вопросы почти праздные, но интересно же...
№ 3800 15-12-2005 06:41 | |
Ответ на »сообщение 3799« (Руслан Богатырев)
___________________________
Кстати, насчет амба.
Провокационный вопрос для знатоков.
Я работаю с модулем. Транслирую. Что берет компилятор в качестве его интерфейса? Бинарную часть ранее оттранслированного интерфейса или мои нынешние звездочки в исходном тексте? По-разному? Если по-разному, то, значит, он отвергнет мои звездочки, а на каком-таком основании? А если всегда правит бинарный SYM-файл, то как быть другим модулям, которые его импортируют? У них же привязка к нему. Раздельная компиляция.
Ну это -- fingerprints разные...
№ 3799 15-12-2005 06:39 | |
Кстати, насчет амба.
Провокационный вопрос для знатоков.
Я работаю с модулем. Транслирую. Что берет компилятор в качестве его интерфейса? Бинарную часть ранее оттранслированного интерфейса или мои нынешние звездочки в исходном тексте? По-разному? Если по-разному, то, значит, он отвергнет мои звездочки, а на каком-таком основании? А если всегда правит бинарный SYM-файл, то как быть другим модулям, которые его импортируют? У них же привязка к нему. Раздельная компиляция.
№ 3798 15-12-2005 06:30 | |
Ответ на »сообщение 3796« (Руслан Богатырев)
___________________________
Погодите, а вот если мы в команде работаем. Там надо жестко -- зафиксировал интерфейс -- и ни-ни, менять нельзя. Под интерфейс же могут специальную железяку делать. А тут кто-то дернул что-то в модуле, ткнул новую звездочку и -- амба!
В том ETH Oberon для того, чтобы изменить интерфейс модуля требуется специальная опция компилятора ( \s).
Так что это не совсем бесконтрольно. :)
Но мысль -- понятна, спасибо.
№ 3797 15-12-2005 06:03 | |
Ответ на »сообщение 3792« (Сергей Губанов)
___________________________
2.Как я понял, недостатки модулей Оберона так и не названы, может стоит их назвать?
Недостаток их в том, что их придумали не в Microsoft.
Это не недостаток модулей, а недостаток почти всего.
№ 3796 15-12-2005 06:01 | |
Ответ на »сообщение 3794« (Takun)
___________________________
Дык это... Если отбросить расширение типа (и рассматривать Оберон как чисто модульный язык), то в нем не поддерживается программирование от интерфейса (модуля). Я не могу задать интерфейс, а затем проверять реализации на соответствие ему.
Ну наконец-то! Верно.
Попробую пояснить, в чем дело. В Обероне (Обероне-2 и Компонентном Паскале) интерфейс и реализация совмещены. Это решает много проблем, но при этом создает недостатки.
Что же за недостатки? Рассмотрим пока лишь один, который верно отметили.
Если с модулями работает один программист (программист-хозяин), то для него не проблема заполучить интерфейс. Нажал кнопку и среда (а может и специальная часть компилятора) извлекает из исходного текста все то, что помечено признаком экспорта (звездочка в Обероне; звездочка и минус в Обероне-2 и Компонентном Паскале).
Кстати, а что он получит? Текстуальную часть интерфейса, которая аналогична тому, что дается компилятору (ну на самом деле компилятору дается немного больше, но это детали).
А есть в этой части комментарии? Вопрос. А нужны? А как же, а как, простите, другие со всем этим хозяйством будут разбираться? Надо бы по-культурному -- написать предусловия и постусловия хотя бы словами.
Ну, выкрутиться можно. В той же ETH Oberon можно писать (** ... *) и такой комментарий автоматически выливается в интерфейс. Ну напридумывали!
А если я сначала проектирую, а потом реализую, как тогда? Ведь мне сначала интерфейс нужен. Извиняйте, тогда делайте пустышку-каркас реализации (да чтобы по правилам скопилировался), а потом из него и извлекайте нужный интерфейс.
А если я хочу там все отформатировать по-красивому, как у людей? Ну, чем богаты. Хотите -- оформляйте.
Простите, но тогда кто будет следить за тем, что моя документация рассинхронизируется в один прекрасный момент с реализацией? Да вы и будете. Отстаньте.
Погодите, а вот если мы в команде работаем. Там надо жестко -- зафиксировал интерфейс -- и ни-ни, менять нельзя. Под интерфейс же могут специальную железяку делать. А тут кто-то дернул что-то в модуле, ткнул новую звездочку и -- амба!
Извиняйте, в Modula-2 таких проблем не было. Там интерфейс отдельно. И транслируется отдельно, и оформляй, как хочешь, и контролируется соответствие вплоть до битика причем и при раздельной компиляции, и при загрузке модулей.
Да, но там были другие проблемы...
№ 3795 15-12-2005 05:43 | |
Ответ на »сообщение 3787« (iZEN)
Мне понравилась ситуация в конексте описания принципа Открыт-Закрыт, где показан явный провал чистого (без ООП) модульного проектирования системы на примере модификации "закрытого" модуля и вынужденной лавинообразной переделки всех клиентских модулей, использующих его.
Наглое враньё!
Расширяемые модульные системы удовлетворяют Open/Close-принципу (открытость для расширения закрытость для модификации) просто напросто по своему определению! Модули (бинарные) - всегда закрыты для модификации. Расширяемая модульная система - всегда открыта для расширения (другими модулями).
Есть система. Нужно её расширить? Прекрасно, (динамически) меняем в ней модули на другие. Все дела.
Что касается "вынужденной лавинообразной переделки всех клиентских модулей", тоже враньё. Читайте диссертацию:
"Separate Compilation and Module Extension" Regis Crelier (th10650)
№ 3794 15-12-2005 05:38 | |
Ответ на »сообщение 3776« (Руслан Богатырев)
___________________________
Ответ на »сообщение 3772« (Takun)
___________________________
Кстати, небольшой вопрос знатокам: в чем заключается явный недостаток языков Оберон, Оберон-2 и Компонентный Паскаль в отношении поддержки модульного программирования (общий для всех этих языков)?
Отсутствием DEFINITION (и возможности его реалзиации) на уровне языка?
Так DEFINITION во всех трех языках автоматически можно получить из текста модуля. А что значит реализация DEFINITION? MODULE реализует тот интерфейс, который задается спецификаторами экспорта (звездочки и минусы). Что же тут не так? Точнее, в чем же недостаток?
Дык это... Если отбросить расширение типа (и рассматривать Оберон как чисто модульный язык), то в нем не поддерживается программирование от интерфейса (модуля). Я не могу задать интерфейс, а затем проверять реализации на соответствие ему.
№ 3793 15-12-2005 05:38 | |
Итак, капсула и интерфейс.
Что помещают в капсулу? Да по-разному. А что хотелось бы? А все, что можно поместить. Хорошо. Смотрим, что есть у нас из сущностей: константы, переменные, типы, процедуры, классы. Ничего не забыли? Вроде бы нет. А, модули! Ну ничего, пока пусть полежат в сторонке.
Значит, если в капсулу все это можно поместить и снаружи сделать интерфейс (описания сущностей и средств доступа), то должно быть неплохо.
Пробуем в качестве капсулы процедуру. Есть у нее интерфейс? Ну да, заголовок процедуры (в Обероне, как и в Modula-2, функции являются частным случаем процедур) -- там есть имя процедуры, параметры с типами, способ их передачи и еще признак функции – тип возвращаемого результата. Можно ли внутри процедуры разместить, например, новый тип? В разных языках – по-разному. Но снаружи к нему доступа не будет. Все, что размещается в процедуре, снаружи не видно. Это как зеркальные очки -- по обратную сторону ничего не видно. Хороша капсула. Разместить внутри можно много чего и вроде как выделяемая часть программы, а назад -- только через параметры. Значит, процедура – это как матрешка, вкладывай друг в друга, а снаружи только нарисованные глазки и расписной сарафанчик.
Ладно, берем тип. У него есть имя. Он определяет набор данных определенной структуры. Если структуру скрываем – все, получили абстрактный тип данных (АТД). Тип, как правило, не бывает сам по себе – должны быть присущие ему (штатные) операции работы с ним. Нештатные операции (манипулирование данными этого типа помимо его определения) рассматривать для простоты не будем. Где у него интерфейс? Как минимум, это его имя. Ничего себе, хорош интерфейс. А еще? А еще заголовки штатных для него процедур. А еще? Хватит. Структуру он показывать наружу не будет. Ну если только ее кусочек. Ага, значит, в принципе к интерфейсу типа можно отнести и часть его внутренней структуры? Так, а что с капсулой, что в тип можно спрятать? Так почти все – константы, переменные, процедуры. А классы? Ну нет, классы не надо. А типы? Если только служебные для него, а такие, чтобы и другие снаружи могли попользоваться, нельзя. Хорошо, значит АТД может быть капсулой с интерфейсом? Получается, может.
Так, теперь берем класс. Да что тут обсуждать – посмотрите на Java. Капсула есть, интерфейс есть, внутри все есть. А новый тип внутри есть? А модуль внутри есть? А другой класс внутри есть? Озадачили, надо подумать. Ну, тогда, наверное, не все. Но ведь капсула и интерфейс, чего еще надо?
Хорошо, смотрим на модуль. Интерфейс есть? Еще бы, ведь его и делят на две части – интерфейсный модуль и исполнительный модуль. В Обероне эти части совмещают, но совмещают текстуально, а на самом деле (для компилятора и клиентов модуля) части разделены. Так, с интерфейсом у модуля более-менее понятно. Теперь капсула. Что в нее можно поместить? Так вроде все можно – переменные, константы, типы, процедуры, классы и модули. Что, и модули? Ну да. Хотя, не совсем. Модули можно было внутрь модуля поместить только в Modula-2. Назывались локальными модулями. Но толку от этого мало. Снаружи их все равно не видать. А зачем были нужны? Так управляли внутри модуля областями видимости – как капсулы для внутреннего, так сказать, употребления. В них тоже много чего можно было поместить. И зачем был такой наворот? Вот и Вирт подумал, зачем? Не используют, лишняя таможня. Вот поэтому и убрал из Modula-2 при переходе к Оберону. Значит, в Обероне их нет? Нет. Т.е. в Обероне модуль внутрь модуля поместить нельзя? Точно, нельзя. Ладно, и с этим разобрались.
№ 3792 15-12-2005 05:36 | |
2.Как я понял, недостатки модулей Оберона так и не названы, может стоит их назвать?
Недостаток их в том, что их придумали не в Microsoft.
Отслеживать это обсуждение
Дополнительная навигация: |
|