Ответ на »сообщение 4011« (Сергей Тарасов)
___________________________
>> Да, без компромиссов... Горизонтальная связь = «слабая» связь. То есть, верхний уровень связывает два элемента так, как считает нужным.
> Понятно. Есть преимушества, есть и недостатки. Обрашения к системным службам проходят иерархию, т.е. потери времени и возможно, информации.
Никакой иерархии обращений нет. Линкер видит, что агрегат не обрабатывает этот вызов (сообщение) и сразу стыкует с тем, кто обрабатывает. Но для разработчика все строго. И автор другого агрегата может «перехватить» вызов. К ошибке это не приведет.

>>> И полиморфизм не нужен.
>> Нужен, причем полноценный. Как, впрочем, и механизм поддержки синонимов.
> Я имел в виду спецификаю пространства имен для интерфейса.
Т.е. в иерархической системе связей вам действительно не надо знать, чей это интерфейс. Он всегда агрегата. А агрегат обеспечивает уникальность имен.
Тогда полиморфизм под вопросом.
Полиморфизм крайне полезная концепция, чтобы понять это надо рассмотреть подуровни системы. Наверное, разговор о системах надо выносить из ветки об Обероне...

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

Просто нельзя обять необятное и переключиться на другую область быстро и при этом бесплатно :)

Видите ли какая ситуация. Хотели Вы того или нет, но в определенном смысле высказали свое неположительное мнение о моей работе. При этом, как я понимаю, не читали ни мои другие работы, посвященные данному направлению, ни книгу Душкина. Сказали, что недостаточно компетенции в Обероне. Но ее видимо должно быть достаточно для Delphi.

Я мог еще как-то понять, если единственной претензией был бы выбранный мной жанр и детальность изложения (пресловутый порог вхождения). "Я бы и хотел по всем 12 пунктам сравнений вам ответить". Достаточно 1-2 пунктов и только по Delphi, уже была бы какая-то конкретика. Надеюсь, вопрос не в финансы здесь упирается?

Ответ на »сообщение 4005« (Илья Ермаков)
___________________________
Прекрасно. Но почему ипморт и полная квалификация противоречат этим принципам?
См. ниже...

Я уже говорил, напомню еще раз - производится всего лишь импорт спецификации интерфейса модуля.
Увидели?.. О каком модуле Вы говорите?.. Нет еще никаких модулей, даже в проекте нет, а Вы уже что-то там импортируете... Откуда?..

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

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

В текущих реализациях Оберон-сред под определенный модульный интерфейс в системе может подставляться только общая, единственная для всего работающего в данный момент экземпляра приложения реализация.
... опять про реализации... :(

Т.е. строим автомобиль. Некоторые модули могут импортировать спецификацию интерфейса "Карбюратор". Они знают, что в автомобиле обязательно будет карбюратор и при том только один. В момент сборки автомобиля мы кладем "в комплект" требующийся двоичный модуль "карбюратор", который совместим с использованными при написании других модулей спецификациями. При запуске автомобиля динамический загрузчик загрузит карбюратор и соединит всех его "клиентов" по интерфейсам с этой конкретной реализацией.
а) откуда взялась спецификация карбюратора?
б) почему некоторые модули знают про карбюратор, зачем им это?
в) кто такие «мы, кладущие двоичный модуль карбюратор»? Разработчики?
г) если мы уже положили «двоичный модуль карбюратор», то что же делает загрузчик?

Это сильно упрощает схему: все "уникальные" блоки системы строятся непосредственно на модулях, блоки, которые могут множиться и версионироваться "на лету" строятся на основе абстрактных и объектных типов данных.
Чего Вам так нравится универсальность модулей... Ну, неудобно молотком щи хлебать... неудобно. Я не отрицаю полезность модулей, но для декларирования при моделировании мне никакие модули не нужны... Нужен инструмент, который проводит это описание через все стадии проектирования, разработки, тестирования и эксплуатации. Это не языковые (в смысле, не 3GL) средства, я об этом с самого начала говорил...

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

Проблема здесь в оценке целевой аудитории, на которую была ориентирована эта статья. Писал ее с ориентацией на исследователей (не практикующих программистов) как выжимку из законодательной базы. Для профессиональных программистов требуется нечто иное, что и предложил обсуждать.
Ну спасибо :) Я и есть исследователь - и по диплому, и по роду занятий. Дельфи для меня - инструмент. Один из. Просто нельзя обять необятное и переключиться на другую область быстро и при этом бесплатно :)

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


Наверное... Объясняю я очень плохо... даже простые вещи...
Нет, наоборот, очень интересно, просто я сторонник "сетевых структур с горизонтальными связями", а не корпораций. По жизни :) ИМХО, на таком уровне искусства декомпозиции личные пристрастия начинают накладывать отпечаток.

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

Отсутствие горизонтальных связей?
Да, без компромиссов... Горизонтальная связь = «слабая» связь. То есть, верхний уровень связывает два элемента так, как считает нужным.
Понятно. Есть преимушества, есть и недостатки. Обрашения к системным службам проходят иерархию, т.е. потери времени и возможно, информации.
Классический пример - обжалование решений судов местного уровня в вышестоящих вплоть до Верховного. Но ответчик и истец могут могут в любой момент сами прийти к мировому соглашению (горизонтальная связь).

Тогда, конечно, не надо специфицировать интерфейс.
Надо, но только между уровнями.
И полиморфизм не нужен.
Нужен, причем полноценный. Как, впрочем, и механизм поддержки синонимов.
Я имел в виду спецификаю пространства имен для интерфейса.
Т.е. в иерархической системе связей вам действительно не надо знать, чей это интерфейс. Он всегда агрегата. А агрегат обеспечивает уникальность имен.
Тогда полиморфизм под вопросом. Потому что он обеспечивает вызов одинаковых по семантике интерфейсов из разных элементов. (Автобус.Ехать(Ленинград) и Поезд.Ехать(Ленинград)). А вызовы такого рода делает только агрегат, который и так знает, кто у него в "хозяйстве" Поезд, а кто Автобус.

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

Сергей, есть небольшая разница между низким порогом входа и тщательным изложением совсем непростых вещей. Вас интересует низкий порог входа в язык Оберон?

Кстати, раз уж заговорили о пороге в контексте ревизии информационных материалов по Оберону. Хотелось бы узнать Ваше (и других участников) мнение о приведенных FAQ для Оберона. Слишком низкий порог, недостаточно низкий?

Ответ на »сообщение 4004« (Сергей Тарасов)
___________________________
Элемент "ничего не должен знать ни о системных службах, ни о смежных элементах" и может "обращаться только к своему агрегату".
Но агрегат тоже является элементом иерархии следуюшего уровня.
Значит к нему применимо то же правило.
Совершенно верно.

Т.о. запрос к смежному элементу или системной службе проходит все уровни до абсолюта (элемента-Бога) и потом так же спускается обратно адресату.
Получается абсурд.
Абсурд?.. Запрос к смежному элементу поступает к агрегату, откуда собственно и попадает к смежному элементу. Но то, что речь идет о смежных элементах знает только... разработчик агрегата – это он положил их в одну «корзину» и связал одной ему ведомой логикой.

Значит, что-то недостаточно понятно на уровне определений и концепции.
Наверное... Объясняю я очень плохо... даже простые вещи...

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

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

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

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

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

Вас интересует низкий порог входа в различие модулей Delphi и Оберона? Ok. Я собственно и сказал, что готов это сделать, но после того как получу предметную критику на упомянутую работу. Осталось только ее дождаться.

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