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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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


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

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

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

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


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

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

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

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

<<<... | 4016—4007 | 4006—3997 | 3996—3987 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 226


№ 4006   17-04-2007 03:42 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4002« (Сергей Тарасов)
___________________________
Отсутствие горизонтальных связей?
Да, без компромиссов... Горизонтальная связь = «слабая» связь. То есть, верхний уровень связывает два элемента так, как считает нужным.

Тогда, конечно, не надо специфицировать интерфейс.
Надо, но только между уровнями.

И полиморфизм не нужен.
Нужен, причем полноценный. Как, впрочем, и механизм поддержки синонимов.


№ 4005   17-04-2007 03:36 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3992« (ASU)
___________________________


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

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

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

Это сильно упрощает схему: все "уникальные" блоки системы строятся непосредственно на модулях, блоки, которые могут множиться и версионироваться "на лету" строятся на основе абстрактных и объектных типов данных.


№ 4004   17-04-2007 03:34 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3992« (ASU)
___________________________


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

Пардон, слона я и не заметил.
Элемент "ничего не должен знать ни о системных службах, ни о смежных элементах" и может "обращаться только к своему агрегату".
Но агрегат тоже является элементом иерархии следуюшего уровня.
Значит к нему применимо то же правило.
Т.о. запрос к смежному элементу или системной службе проходит все уровни до абсолюта (элемента-Бога) и потом так же спускается обратно адресату.
Получается абсурд.
Значит, что-то недостаточно понятно на уровне определений и концепции.


№ 4003   17-04-2007 03:33 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3997« (MS)
___________________________
ООП vs Модульное программирование?
С этим не ко мне... С моей точки зрения, есть четкая последовательность:
процедуры -> библиотеки -> модули -> объекты -> агрегаты -> системы...
и никаких "противоборств"...


№ 4002   17-04-2007 03:26 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3992« (ASU)
___________________________


Каждый элемент какого-либо из уровней может обращаться только к своему агрегату, он ничего не должен знать ни о системных службах, ни о смежных элементах. Соответственно, интерфейсы системных служб дополняют межуровневые интерфейсы, так, как будто они принадлежат агрегату. И агрегат имеет возможность перехватывать обращения своих элементов.
В остальном придерживаются строгого правила: интерфейсы локализованы между двумя уровнями. Поэтому не происходит никакой путаницы с именами и не требуется вводить дополнительные правила, поддерживающие пространства имен. Данное требование должно быть «известно» и средствам трансляции, и средствам загрузки, и средствам коммутации.

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


№ 4001   17-04-2007 03:22 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3998« (Сергей Тарасов)
___________________________

Я бы и хотел по всем 12 пунктам сравнений вам ответить, но понял, что в отсутствии опыта работы с Обероном это займет непозволительно много времени.

Чтобы задача не казалась такой неподъемной, ее можно упростить. Есть специалисты по одному языку, участвующему в сравнении (Delphi), есть по другому (Oberon). Достаточно отметить некорректность (неполноту, ошибочность) утверждений, относящихся к соответствующим языкам. Либо отметить некорректность в отношении методики сопоставления (не те критерии, не те разделы).

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


№ 4000   17-04-2007 03:19 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3982« (Сергей Перовский)
___________________________

Ответ на »сообщение 3965« (AVC)
___________________________
Таким образом мы получаем гораздо более слабые связи между текстами модулей. Поскольку интерфейсы регистрируются и вызываются при помощи GUID никакой конфликт имен невозможен.

Поучительно, что в токе нет Микрософт отказались от обязательной центральной регистрации сборок...
Потому что такое "ослабление связей" требуется не каждый день.

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


№ 3999   17-04-2007 03:14 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3998« (Сергей Тарасов)
___________________________

Сергей, есть небольшая разница между низким порогом входа и тщательным изложением совсем непростых вещей. Вас интересует низкий порог входа в язык Оберон? См. http://www.oberon2005.ru/obe_faq1.html и http://www.oberon2005.ru/obe_faq2.html

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


№ 3998   17-04-2007 03:08 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3853« (Владимир Лось)
___________________________

Семь лет мы тут воду в ступе толчём, а где результаты?
Инфо21 что-то тут о курсах говорил - не видел я что-то на развалах хотя бы брошюрок на тему КП с надписью на титульном листе "рекомендовано... для применения в курсах обучения"... Академик, ведь - это не вася пупкин - из заштатного ПТУ... Всё прекрасно, но как-то "ограниченно-точечно-кулуарно"...
Душкин вон напечатал книгу по Хаскелю. Книжка немного сумбурная, слабая, оформлена - из рук вон... Но посмотрите на эффект, сколько дискуссий возникло. С полок её смели (говорят даже издетельство ещё раз отпечатает партию), Душкин вторую книгу готовит. У меня студенты и знакомые стали связку слов "хаскель-ФП-книга Душкина" ЗАМЕТНО чаще употреблять... ПОстепено, кстати, складывается впечатление, что все, сколь-нибудь значимые и передовые исследования в мире программирования перемещаются в нишу "хаскель" и "ФП"... Не знаю, насколько это верно объективно, но "информационный фон" именно таким стал...

А здесь - что? Тем более при вашей лично, Руслан, кипучей деятельности, много- и связнословии и возможности контакта с "прессой"?


Полностью вас поддержу.
Руслан, я глянул на вашу статью о сравнениях. Она является типичным примером того, о чем говорит Владимир.
Я бы и хотел по всем 12 пунктам сравнений вам ответить, но понял, что в отсутствии опыта работы с Обероном это займет непозволительно много времени. На беготню по ссылкам (ссылка на книги по описанию языка так же полезны, как и на большую советскую энциклопедию), на поиск определений и их сопоставлений, на поиск примеров и контрпримеров.
Поэтому не стоит удивляться, что студенты начинают употреблять связку слов "хаскель-ФП-книга Душкина". Видимо (книгу не читал), Душкин сумел передать сложные веши простыми словами и на конкретных примерах.
Низкий порог входа - великое дело. И совершенно необязательно за низким порогом стоит примитивная технология. Это может быть первый шаг к сложной системе, первый шаг без которого путь в 1000 шагов никогда не начнется.


№ 3997   17-04-2007 03:08 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3994« (ASU)
___________________________

Ответ на »сообщение 3993« (MS)
___________________________
ИМХО это дерево наследования.
Агрегация...


ООП vs Модульное программирование?


<<<... | 4016—4007 | 4006—3997 | 3996—3987 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 226


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

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

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

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

Перейти на конкретную страницу по номеру
  
Время на сайте: 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» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
Все используемые на сайте торговые марки являются собственностью их производителей.

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