Ответ на »сообщение 4110« (Руслан Богатырев)
___________________________
>>Скажите, а когда адепты структурного программирования боролись с GoTo, то это чей вкус был?
> Они это обосновывали. Достаточно убедительно.
Ага... Это чем они обосновывали? Сравнением со спагетти?

Ваших обоснований (равно как и тезисов) я пока не вижу. Увы. Мы даже не знаем, что с чем сопоставляем.
Хм... И для чего я описывал процесс создания системы...
Пора заканчивать беседу, по пять раз одно и то же... это перебор...

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

Вместо FROM Math IMPORT Sin я бы предпочел неписать просто IMPORT Sin, а насчет From пусть болит голова у того, кто будет собирать из модулей систему - у него должен быть другой инструмент.

Ну вот и здесь наступает ясность. Т.е. проблема не в том, квалифицирующий импорт или неквалифицирующий, а в импорте вообще. Если бы был импорт просто источника без sin -- другое дело, мы его уже разбирали. А IMPORT sin без указания источника -- это не импорт, это уведомление компилятору, что здесь его компетенция закончилась. Деньги будут позже. Берем сущность в кредит. Мы потихоньку пришли в пещеры доисторической эпохи с вывеской "независимая компиляция".

Итак, мы просто используем некое внешнее имя без указания источника. Теперь возникает следующий вопрос: "Может ли компилятор самостоятельно выяснить все атрибуты этого имени?"
1. Ответ: Yes -- неквалифицирующий импорт вида FROM-IMPORT
2. Ответ: No -- компетенция линкера

Значит, на уровне языка нет проверки атрибутов внешней сущности, ибо о ней компилятор не имеет никакой информации (эта информация в интерфейсах или их заменителях, а их нет). Он верит на слово программисту, что потом кто-то этот вопрос снимет.

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

Call(entity,params)

Конкретизацией будет заниматься внеязыковой механизм, который на этапе выполнения/загрузки совместит имя сущности с ее представителем (например, persistent object). Хочется отконтролировать до загрузки? Ok. Это делает наш persistent-линкер: сверяется по таблицам символов -- есть такая сущность или обманывают? Это нельзя реализовать в Обероне?

Как я понимаю, нам говорят: "Долой контроль языка! Анархия -- мать порядка!"  Анархию можно всегда устроить. А вот контроль получить, когда его в языке нет, -- увы.

Ответ на »сообщение 4108« (Руслан Богатырев)
___________________________
Как Вы думаете, если набор модулей сливается в один (то бишь в "программу"), можно по дороге что-то потерять? А что?
Да, безусловно. Вы потеряете формализованную логику системы.

Интерфейсы -- это абстрагирование.
Хм?.. Кто это Вам сказал?.. Вставьте флэшку в USB порт...

Если пишет один и тот же человек (программист-хозяин по Ершову), для него абстрагирование есть просто некое удобство (не все бумажки на столе, а в ящичках, по полочкам, как у больших людей). Все равно нутро все знает. Сам ведь пишет.
Правда?.. Нет, Вы меня сильно удивили... Например, я не знаю содержания систем, которые работают у моих заказчиков... и знать нет никакой необходимости. Как Вы думаете, разработчики чипсетов, материнских и прочих плат, знают, какой компьютер стоит под моим столом?..

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

И c чего это вдруг наша замечательная система со всякими там навороченными связями на глазах превратилась в обыденную программу, недостойную даже нашего внимания за своей примитивностью? Был красивый хрустальный дворец, а осталась жалкая лужица...
Жалко... :(

Ответ на »сообщение 4102« (MS)
___________________________
>>>Т.е. Есть некий более или менее глобальный список экспортируемых типов. Вы посылаете запрос диспетчеру на определённый тип (например sin), он просматрывает список экспорта, и при совпадении типов формирует связь?
Боюсь, что автоматическая сборка в таком виде невозможна.
Только  при глобальной регистрации имен интерфейсов и импорте, квалифицируемом кодом интерфейса, как сделано в СОМ.
А так придется сшивать модули вручную, заполняя таблицу экспорта-импорта. Я только хочу обратить внимание, что таблицу импорта лучше отделить от текста модуля во избежании ошибок.

Ответ на »сообщение 4107« (MS)
___________________________
Читал, толька, наверно прогядел :-(.
А в каком письме приведено сравнение объекта и модуля?
Там нет чистого сравнения, там показано развитие.
Модуль в отличие от "объектов" не поддерживает два из трех принципов ООП: полиморфизм и наследование. По идеологии модули остались ближе к библиотекам, чем к объектам. Объекты отождествляются с реальными или виртуальными сущностями внешнего мира и в программы динамически создают множество объектов, поддерживая соответствие с сущностями внешнего мира. Модули редко множатся в рамках одной задачи и, скорее такое размножение связано, с особенностью задачи или метода ее решения, а не с попыткой моделировать внешний мир.

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

Его предназначение – написание программных модулей, получение программ. Кода в него ввели механизмы межмодульной связи и стали применять для получения сущностей состоящих из нескольких модулей... то это и есть «не туда применять».

О, как далеко мы приехали! Если вводится в языке понятие "модуль" как сущности верхнего уровня, автоматически возникает необходимость в межмодульных связях. Вы против этой сущности в языке программирования? Назовите ее заменяющую. Что-то ведь должно быть сущностью верхнего уровня в языке. Напомню, говорим о языке программирования (чтобы не было здесь недопонимания).

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

Скажите, а когда адепты структурного программирования боролись с GoTo, то это чей вкус был?

Они это обосновывали. Достаточно убедительно. Ваших обоснований (равно как и тезисов) я пока не вижу. Увы. Мы даже не знаем, что с чем сопоставляем.

Ответ на »сообщение 4099« (Руслан Богатырев)
___________________________
Стоп. Что есть дурной тон?
Очень странный вопрос...

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

А теперь чуть подробнее о назначении инструмента. Возьмите Оберон. Назовите в нем "инструмент". Скажите, в чем его высочайшее предназначение и для чего его вдруг стали не туда применять.
Его предназначение – написание программных модулей, получение программ. Кода в него ввели механизмы межмодульной связи и стали применять для получения сущностей состоящих из нескольких модулей... то это и есть «не туда применять».

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

Вариант со слабыми связями, когда логика управления частями вынесена на отдельный уровень. Что это за логика? Все просто «разные части: синтаксический анализатор, лексический анализатор, генератор кода» ( »сообщение 4075« ).  синтаксический анализатор -> лексический анализатор -> генератор кода. Предположим, что потребовалось добавить препроцессор... В случае с программой или «монолитом» надо все разобрать, встроить и откомпилировать. И чем больше внутренних связей, тем труднее выполнить эту работу.

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

И c чего это вдруг наша замечательная система со всякими там навороченными связями на глазах превратилась в обыденную программу, недостойную даже нашего внимания за своей примитивностью? Был красивый хрустальный дворец, а осталась жалкая лужица...

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

Ответ на »сообщение 4095« (MS)
___________________________
Понятно. А чем тогда модуль отличается от объекта?
Вроде как объект имеет данные и знает что с ними делать.
Значит не читали...

Читал, толька, наверно прогядел :-(.
А в каком письме приведено сравнение объекта и модуля?
Или определение объекта? (если не сложно полную ссылку)