Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 4116 18-04-2007 06:19 | |
Ответ на »сообщение 4110« (Руслан Богатырев)
___________________________
>>Скажите, а когда адепты структурного программирования боролись с GoTo, то это чей вкус был?
> Они это обосновывали. Достаточно убедительно.
Ага... Это чем они обосновывали? Сравнением со спагетти?
Ваших обоснований (равно как и тезисов) я пока не вижу. Увы. Мы даже не знаем, что с чем сопоставляем.
Хм... И для чего я описывал процесс создания системы...
Пора заканчивать беседу, по пять раз одно и то же... это перебор...
№ 4115 18-04-2007 06:16 | |
Ответ на »сообщение 4088« (Сергей Перовский)
___________________________
Вместо FROM Math IMPORT Sin я бы предпочел неписать просто IMPORT Sin, а насчет From пусть болит голова у того, кто будет собирать из модулей систему - у него должен быть другой инструмент.
Ну вот и здесь наступает ясность. Т.е. проблема не в том, квалифицирующий импорт или неквалифицирующий, а в импорте вообще. Если бы был импорт просто источника без sin -- другое дело, мы его уже разбирали. А IMPORT sin без указания источника -- это не импорт, это уведомление компилятору, что здесь его компетенция закончилась. Деньги будут позже. Берем сущность в кредит. Мы потихоньку пришли в пещеры доисторической эпохи с вывеской "независимая компиляция".
Итак, мы просто используем некое внешнее имя без указания источника. Теперь возникает следующий вопрос: "Может ли компилятор самостоятельно выяснить все атрибуты этого имени?"
1. Ответ: Yes -- неквалифицирующий импорт вида FROM-IMPORT
2. Ответ: No -- компетенция линкера
Значит, на уровне языка нет проверки атрибутов внешней сущности, ибо о ней компилятор не имеет никакой информации (эта информация в интерфейсах или их заменителях, а их нет). Он верит на слово программисту, что потом кто-то этот вопрос снимет.
Простите, чем это отличается от обычной процедуры, которая вызывает внешнюю сущность и передает ей параметры? Она делает это без контроля со стороны языка (компилятора). Через текстовые строки. Одна -- текстовое имя сущности, другая -- ее параметры.
Call(entity,params)
Конкретизацией будет заниматься внеязыковой механизм, который на этапе выполнения/загрузки совместит имя сущности с ее представителем (например, persistent object). Хочется отконтролировать до загрузки? Ok. Это делает наш persistent-линкер: сверяется по таблицам символов -- есть такая сущность или обманывают? Это нельзя реализовать в Обероне?
Как я понимаю, нам говорят: "Долой контроль языка! Анархия -- мать порядка!" Анархию можно всегда устроить. А вот контроль получить, когда его в языке нет, -- увы.
№ 4114 18-04-2007 06:16 | |
Ответ на »сообщение 4108« (Руслан Богатырев)
___________________________
Как Вы думаете, если набор модулей сливается в один (то бишь в "программу"), можно по дороге что-то потерять? А что?
Да, безусловно. Вы потеряете формализованную логику системы.
Интерфейсы -- это абстрагирование.
Хм?.. Кто это Вам сказал?.. Вставьте флэшку в USB порт...
Если пишет один и тот же человек (программист-хозяин по Ершову), для него абстрагирование есть просто некое удобство (не все бумажки на столе, а в ящичках, по полочкам, как у больших людей). Все равно нутро все знает. Сам ведь пишет.
Правда?.. Нет, Вы меня сильно удивили... Например, я не знаю содержания систем, которые работают у моих заказчиков... и знать нет никакой необходимости. Как Вы думаете, разработчики чипсетов, материнских и прочих плат, знают, какой компьютер стоит под моим столом?..
Значит, снимаются межмодульные барьеры (для абстракции они -- фикция, только контроль областей видимости, чтоб лишний раз щелкнуть по носу незадачливого программиста).
Исходные утверждения оказались неверны...
И c чего это вдруг наша замечательная система со всякими там навороченными связями на глазах превратилась в обыденную программу, недостойную даже нашего внимания за своей примитивностью? Был красивый хрустальный дворец, а осталась жалкая лужица...
Жалко... :(
№ 4113 18-04-2007 06:09 | |
Ответ на »сообщение 4102« (MS)
___________________________
>>>Т.е. Есть некий более или менее глобальный список экспортируемых типов. Вы посылаете запрос диспетчеру на определённый тип (например sin), он просматрывает список экспорта, и при совпадении типов формирует связь?
Боюсь, что автоматическая сборка в таком виде невозможна.
Только при глобальной регистрации имен интерфейсов и импорте, квалифицируемом кодом интерфейса, как сделано в СОМ.
А так придется сшивать модули вручную, заполняя таблицу экспорта-импорта. Я только хочу обратить внимание, что таблицу импорта лучше отделить от текста модуля во избежании ошибок.
№ 4112 18-04-2007 06:07 | |
Ответ на »сообщение 4107« (MS)
___________________________
Читал, толька, наверно прогядел :-(.
А в каком письме приведено сравнение объекта и модуля?
Там нет чистого сравнения, там показано развитие.
Модуль в отличие от "объектов" не поддерживает два из трех принципов ООП: полиморфизм и наследование. По идеологии модули остались ближе к библиотекам, чем к объектам. Объекты отождествляются с реальными или виртуальными сущностями внешнего мира и в программы динамически создают множество объектов, поддерживая соответствие с сущностями внешнего мира. Модули редко множатся в рамках одной задачи и, скорее такое размножение связано, с особенностью задачи или метода ее решения, а не с попыткой моделировать внешний мир.
№ 4111 18-04-2007 05:55 | |
Ответ на »сообщение 4109« (ASU)
___________________________
Его предназначение – написание программных модулей, получение программ. Кода в него ввели механизмы межмодульной связи и стали применять для получения сущностей состоящих из нескольких модулей... то это и есть «не туда применять».
О, как далеко мы приехали! Если вводится в языке понятие "модуль" как сущности верхнего уровня, автоматически возникает необходимость в межмодульных связях. Вы против этой сущности в языке программирования? Назовите ее заменяющую. Что-то ведь должно быть сущностью верхнего уровня в языке. Напомню, говорим о языке программирования (чтобы не было здесь недопонимания).
№ 4110 18-04-2007 05:52 | |
Ответ на »сообщение 4109« (ASU)
___________________________
Скажите, а когда адепты структурного программирования боролись с GoTo, то это чей вкус был?
Они это обосновывали. Достаточно убедительно. Ваших обоснований (равно как и тезисов) я пока не вижу. Увы. Мы даже не знаем, что с чем сопоставляем.
№ 4109 18-04-2007 05:49 | |
Ответ на »сообщение 4099« (Руслан Богатырев)
___________________________
Стоп. Что есть дурной тон?
Очень странный вопрос...
Вам что-то не нравится, когда в язык вводятся какие-то дополнительные средства? Это Ваш вкус.
Скажите, а когда адепты структурного программирования боролись с GoTo, то это чей вкус был?
А теперь чуть подробнее о назначении инструмента. Возьмите Оберон. Назовите в нем "инструмент". Скажите, в чем его высочайшее предназначение и для чего его вдруг стали не туда применять.
Его предназначение – написание программных модулей, получение программ. Кода в него ввели механизмы межмодульной связи и стали применять для получения сущностей состоящих из нескольких модулей... то это и есть «не туда применять».
№ 4108 18-04-2007 05:48 | |
Ответ на »сообщение 4097« (ASU)
___________________________
Вариант со слабыми связями, когда логика управления частями вынесена на отдельный уровень. Что это за логика? Все просто «разные части: синтаксический анализатор, лексический анализатор, генератор кода» ( »сообщение 4075« ). синтаксический анализатор -> лексический анализатор -> генератор кода. Предположим, что потребовалось добавить препроцессор... В случае с программой или «монолитом» надо все разобрать, встроить и откомпилировать. И чем больше внутренних связей, тем труднее выполнить эту работу.
Как Вы думаете, если набор модулей сливается в один (то бишь в "программу"), можно по дороге что-то потерять? А что? Интерфейсы -- это абстрагирование. Если пишет один и тот же человек (программист-хозяин по Ершову), для него абстрагирование есть просто некое удобство (не все бумажки на столе, а в ящичках, по полочкам, как у больших людей). Все равно нутро все знает. Сам ведь пишет. Значит, снимаются межмодульные барьеры (для абстракции они -- фикция, только контроль областей видимости, чтоб лишний раз щелкнуть по носу незадачливого программиста).
И c чего это вдруг наша замечательная система со всякими там навороченными связями на глазах превратилась в обыденную программу, недостойную даже нашего внимания за своей примитивностью? Был красивый хрустальный дворец, а осталась жалкая лужица...
№ 4107 18-04-2007 05:43 | |
Ответ на »сообщение 4105« (ASU)
___________________________
Ответ на »сообщение 4095« (MS)
___________________________
Понятно. А чем тогда модуль отличается от объекта?
Вроде как объект имеет данные и знает что с ними делать.
Значит не читали...
Читал, толька, наверно прогядел :-(.
А в каком письме приведено сравнение объекта и модуля?
Или определение объекта? (если не сложно полную ссылку)
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|