Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Базарная площадь
  
О разделе

Основная страница

Группы обсуждений


Тематический каталог обсуждений

Архив

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  15:28[Войти] | [Зарегистрироваться]
Обсуждение темы:
Оберон-технология: особенности и перспективы


Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение. 

Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру


Всего в теме 6256 сообщений

Добавить свое сообщение

Отслеживать это обсуждение

Обсуждение из раздела
Школа ОБЕРОНА

<<<... | 4126—4117 | 4116—4107 | 4106—4097 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 215


№ 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)
___________________________
Понятно. А чем тогда модуль отличается от объекта?
Вроде как объект имеет данные и знает что с ними делать.
Значит не читали...


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


<<<... | 4126—4117 | 4116—4107 | 4106—4097 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 215


Добавить свое сообщение

Отслеживать это обсуждение

Дополнительная навигация:
Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру
  
Время на сайте: GMT минус 5 часов

Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter.
Функция может не работать в некоторых версиях броузеров.

Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

 
© При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
Все используемые на сайте торговые марки являются собственностью их производителей.

Яндекс цитирования