Ну это -- fingerprints разные...

Ага. "Отпечатки пальцев" видимо фиксируют все "прожилки" интерфейса.

А если мне важно знать дату снятия отпечатка? Или это не фиксируется? А если мне важно знать изменение порядка следования описаний (т.е. они те же, но в другом порядке)? Это контролируется. Вопросы почти праздные, но интересно же...

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

Кстати, насчет амба.

Провокационный вопрос для знатоков.

Я работаю с модулем. Транслирую. Что берет компилятор в качестве его интерфейса? Бинарную часть ранее оттранслированного интерфейса или мои нынешние звездочки в исходном тексте? По-разному? Если по-разному, то, значит, он отвергнет мои звездочки, а на каком-таком основании? А если всегда правит бинарный SYM-файл, то как быть другим модулям, которые его импортируют? У них же привязка к нему. Раздельная компиляция.


Ну это -- fingerprints разные...

Кстати, насчет амба.

Провокационный вопрос для знатоков.

Я работаю с модулем. Транслирую. Что берет компилятор в качестве его интерфейса? Бинарную часть ранее оттранслированного интерфейса или мои нынешние звездочки в исходном тексте? По-разному? Если по-разному, то, значит, он отвергнет мои звездочки, а на каком-таком основании? А если всегда правит бинарный SYM-файл, то как быть другим модулям, которые его импортируют? У них же привязка к нему. Раздельная компиляция.

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


Погодите, а вот если мы в команде работаем. Там надо жестко -- зафиксировал интерфейс -- и ни-ни, менять нельзя. Под интерфейс же могут специальную железяку делать. А тут кто-то дернул что-то в модуле, ткнул новую звездочку и -- амба!


В том ETH Oberon для того, чтобы изменить интерфейс модуля требуется специальная опция компилятора (\s).
Так что это не совсем бесконтрольно. :)
Но мысль -- понятна, спасибо.

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

2.Как я понял, недостатки модулей Оберона так и не названы, может стоит их назвать?

Недостаток их в том, что их придумали не в Microsoft.

Это не недостаток модулей, а недостаток почти всего.

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

Дык это... Если отбросить расширение типа (и рассматривать Оберон как чисто модульный язык), то в нем не поддерживается программирование от интерфейса (модуля). Я не могу задать интерфейс, а затем проверять реализации на соответствие ему.

Ну наконец-то! Верно.

Попробую пояснить, в чем дело. В Обероне (Обероне-2 и Компонентном Паскале) интерфейс и реализация совмещены. Это решает много проблем, но при этом создает недостатки.

Что же за недостатки? Рассмотрим пока лишь один, который верно отметили.

Если с модулями работает один программист (программист-хозяин), то для него не проблема заполучить интерфейс. Нажал кнопку и среда (а может и специальная часть компилятора) извлекает из исходного текста все то, что помечено признаком экспорта (звездочка в Обероне; звездочка и минус в Обероне-2 и Компонентном Паскале).

Кстати, а что он получит? Текстуальную часть интерфейса, которая аналогична тому, что дается компилятору (ну на самом деле компилятору дается немного больше, но это детали).

А есть в этой части комментарии? Вопрос. А нужны? А как же, а как, простите, другие со всем этим хозяйством будут разбираться? Надо бы по-культурному -- написать предусловия и постусловия хотя бы словами.

Ну, выкрутиться можно. В той же ETH Oberon можно писать (** ... *) и такой комментарий автоматически выливается в интерфейс. Ну напридумывали!

А если я сначала проектирую, а потом реализую, как тогда? Ведь мне сначала интерфейс нужен. Извиняйте, тогда делайте пустышку-каркас реализации (да чтобы по правилам скопилировался), а потом из него и извлекайте нужный интерфейс.

А если я хочу там все отформатировать по-красивому, как у людей? Ну, чем богаты. Хотите -- оформляйте.

Простите, но тогда кто будет следить за тем, что моя документация рассинхронизируется в один прекрасный момент с реализацией? Да вы и будете. Отстаньте.

Погодите, а вот если мы в команде работаем. Там надо жестко -- зафиксировал интерфейс -- и ни-ни, менять нельзя. Под интерфейс же могут специальную железяку делать. А тут кто-то дернул что-то в модуле, ткнул новую звездочку и -- амба!

Извиняйте, в Modula-2 таких проблем не было. Там интерфейс отдельно. И транслируется отдельно, и оформляй, как хочешь, и контролируется соответствие вплоть до битика причем и при раздельной компиляции, и при загрузке модулей.

Да, но там были другие проблемы...

Ответ на »сообщение 3787« (iZEN)
Мне понравилась ситуация в конексте описания принципа Открыт-Закрыт, где показан явный провал чистого (без ООП) модульного проектирования системы на примере модификации "закрытого" модуля и вынужденной лавинообразной переделки всех клиентских модулей, использующих его.

Наглое враньё!

Расширяемые модульные системы удовлетворяют Open/Close-принципу (открытость для расширения закрытость для модификации) просто напросто по своему определению! Модули (бинарные) - всегда закрыты для модификации. Расширяемая модульная система - всегда открыта для расширения (другими модулями).

Есть система. Нужно её расширить? Прекрасно, (динамически) меняем в ней модули на другие. Все дела.

Что касается "вынужденной лавинообразной переделки всех клиентских модулей", тоже враньё. Читайте диссертацию:
"Separate Compilation and Module Extension" Regis Crelier (th10650)

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

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

Кстати, небольшой вопрос знатокам: в чем заключается явный недостаток языков Оберон, Оберон-2 и Компонентный Паскаль в отношении поддержки модульного программирования (общий для всех этих языков)?

Отсутствием DEFINITION (и возможности его реалзиации) на уровне языка?

Так DEFINITION во всех трех языках автоматически можно получить из текста модуля. А что значит реализация DEFINITION? MODULE реализует тот интерфейс, который задается спецификаторами экспорта (звездочки и минусы). Что же тут не так? Точнее, в чем же недостаток?

Дык это... Если отбросить расширение типа (и рассматривать Оберон как чисто модульный язык), то в нем не поддерживается программирование от интерфейса (модуля). Я не могу задать интерфейс, а затем проверять реализации на соответствие ему.

Итак, капсула и интерфейс.

Что помещают в капсулу? Да по-разному. А что хотелось бы? А все, что можно поместить. Хорошо. Смотрим, что есть у нас из сущностей: константы, переменные, типы, процедуры, классы. Ничего не забыли? Вроде бы нет. А, модули! Ну ничего, пока пусть полежат в сторонке.

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

Пробуем в качестве капсулы процедуру. Есть у нее интерфейс? Ну да, заголовок процедуры (в Обероне, как и в Modula-2, функции являются частным случаем процедур) -- там есть имя процедуры, параметры с типами, способ их передачи и еще признак функции – тип возвращаемого результата. Можно ли внутри процедуры разместить, например, новый тип? В разных языках – по-разному. Но снаружи к нему доступа не будет. Все, что размещается в процедуре, снаружи не видно. Это как зеркальные очки -- по обратную сторону ничего не видно. Хороша капсула. Разместить внутри можно много чего и вроде как выделяемая часть программы, а назад -- только через параметры. Значит, процедура – это как матрешка, вкладывай друг в друга, а снаружи только нарисованные глазки и расписной сарафанчик.

Ладно, берем тип. У него есть имя. Он определяет набор данных определенной структуры. Если структуру скрываем – все, получили абстрактный тип данных (АТД). Тип, как правило, не бывает сам по себе – должны быть присущие ему (штатные) операции работы с ним. Нештатные операции (манипулирование данными этого типа помимо его определения) рассматривать для простоты не будем. Где у него интерфейс? Как минимум, это его имя. Ничего себе, хорош интерфейс. А еще? А еще заголовки штатных для него процедур. А еще? Хватит. Структуру он показывать наружу не будет. Ну если только ее кусочек. Ага, значит, в принципе к интерфейсу типа можно отнести и часть его внутренней структуры? Так, а что с капсулой, что в тип можно спрятать? Так почти все – константы, переменные, процедуры. А классы? Ну нет, классы не надо. А типы? Если только служебные для него, а такие, чтобы и другие снаружи могли попользоваться, нельзя. Хорошо, значит АТД может быть капсулой с интерфейсом? Получается, может.

Так, теперь берем класс. Да что тут обсуждать – посмотрите на Java. Капсула есть, интерфейс есть, внутри все есть. А новый тип внутри есть? А модуль внутри есть? А другой класс внутри есть? Озадачили, надо подумать. Ну, тогда, наверное, не все. Но ведь капсула и интерфейс, чего еще надо?

Хорошо, смотрим на модуль. Интерфейс есть? Еще бы, ведь его и делят на две части – интерфейсный модуль и исполнительный модуль. В Обероне эти части совмещают, но совмещают текстуально, а на самом деле (для компилятора и клиентов модуля) части разделены. Так, с интерфейсом у модуля более-менее понятно. Теперь капсула. Что в нее можно поместить? Так вроде все можно – переменные, константы, типы, процедуры, классы и модули. Что, и модули? Ну да. Хотя, не совсем. Модули можно было внутрь модуля поместить только в Modula-2. Назывались локальными модулями. Но толку от этого мало. Снаружи их все равно не видать. А зачем были нужны? Так управляли внутри модуля областями видимости – как капсулы для внутреннего, так сказать, употребления. В них тоже много чего можно было поместить. И зачем был такой наворот? Вот и Вирт подумал, зачем? Не используют, лишняя таможня. Вот поэтому и убрал из Modula-2 при переходе к Оберону. Значит, в Обероне их нет? Нет. Т.е. в Обероне модуль внутрь модуля поместить нельзя? Точно, нельзя. Ладно, и с этим разобрались.

2.Как я понял, недостатки модулей Оберона так и не названы, может стоит их назвать?

Недостаток их в том, что их придумали не в Microsoft.