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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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


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

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

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

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


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

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

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

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

<<<... | 4046—4037 | 4036—4027 | 4026—4017 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 223


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

Мы только что договорились, что это разные вещи :)
DEFINITION - часть модуля, значит мы намертво пристыковываемся к модулю.
Если нужно заменить модуль на другой (естественно с другим именем), то придется менять хотя бы одну строчку в каждом импортирующем модуле.
А как же насчет "без перетрансляции"?


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

Видятся следующие варианты соответствия "один интерфейс -- несколько реализаций":
1. Эволюция версий (динамика разработки)
2. Разные варианты с учетом доп. конкретизации (платформа, ресурсы, схемы оптимизации и т.п.)

Эти варианты безотносительно статического/динамического воплощения связи (может быть и так, и так).

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

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

Возвращаясь к Вашему утверждению. DEFINITION не привязан жестко к модулю (реализации). В Обероне -- это просто базовая связь (из модуля автоматически по разметке экспорта генерируется интерфейс). Данная схема может быть дополнена/изменена без изменения языка. Как -- я уже разъяснял.


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

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


Все это многократно обсуждалось.
Соответствующие понятия "коммутация", "инсталляция" и т.д. разъяснялись не раз Русланом и Ильей.
Сейчас я просто прошу Вас задуматься над фактом, что в Обероне на самом деле можно поменять на лету модуль, обеспечивающий ту или иную функциональность.
 AVC


№ 4034   17-04-2007 06:27 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4027« (Руслан Богатырев)
___________________________
>>>в Обероне квалифицируется интерфейс (DEFINITION)
Мы только что договорились, что это разные вещи :)
DEFINITION - часть модуля, значит мы намертво пристыковываемся к модулю.
Если нужно заменить модуль на другой (естественно с другим именем), то придется менять хотя бы одну строчку в каждом импортирующем модуле.
А как же насчет "без перетрансляции"?
Вынесение таблицы синонимов (по сути таблицы интерфейс - модуль реализации) из модуля в отдельную сущность заметно увеличило бы гибкость межмодульных отношений.


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

>>>В русском языке термин "системное программирование" произошел не от филосовского или научного понятия "система", а от конкретного (и не очень удачного) термина "операционная система". Так уж получилось.

Применительно к Оберону -- не так уж неудачно. :)
В Оберон-системе любой модуль есть расширение операционной системы.
 AVC


№ 4032   17-04-2007 06:08 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4028« (Илья Ермаков)
___________________________
>>>Можно позаимствовать что-то из Ады
Собственно, про это и звук :)
Писать заглушку, а потом ее подменять, не слишком хороший стиль.
Возможность независимого описания интерфейсов и наследования интерфейсов очень хорошая возможность.


№ 4031   17-04-2007 06:07 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 4030« (Trurl)
___________________________

Ответ на »сообщение 3995« (Илья Ермаков)
___________________________
Хм... В смысле "селекторы"?
В смысле DevSelectors. ;-) Я о них тут как-то писал уже.

Елки-палки... Сколько работаю - не знал про эту штуку. Модуль-то недокументированный. А как ими пользоваться?
Давайте перейдем на наш форум, чтобы не захламлять ветку:
http://forum.oberoncore.ru/viewtopic.php?p=4410#4410


№ 4030   17-04-2007 05:47 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3995« (Илья Ермаков)
___________________________

Хм... В смысле "селекторы"?
В смысле DevSelectors. ;-) Я о них тут как-то писал уже.


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

Вы именуете эти стандарты протоколами, но термин интерфейс гораздо точнее отражает их смысл.

Похоже, Вы меня неправильно поняли (либо я выразился недостаточно понятно). В »сообщение 3996« я говорил о различиях между интерфейсами и протоколами, поскольку ASU поставил их на одну доску. Что касается Оберона, то у него есть спецификации модуля (DEFINITION), которые можно называть интерфейсами модуля (а не интерфейсами системы, ее уровней/слоев). Это спецификация "точек" установления взаимодействия модуля с модулем (сущностей одного модуля с сущностями другого), т.е. интерфейс между модулями.

Что касается протоколов, то в классическом Обероне они в явном виде на уровне спецификаций не поддерживаются. Вообще. Это не есть хорошо (с определенной точки зрения). Но это так.


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

Ответ на »сообщение 4019« (Руслан Богатырев)
___________________________
Отлично, избавились от терминологической путаницы. Теперь давайте определимся снова, имя ЧЕГО должно использоваться для квалификации импорта?
ASU считает, что это должно быть имя интерфейса, а не модуля, так получается гораздо  более гибко. Присоединяюсь.

В квалификации импорта указывается имя интерфейса. Просто в базисном случае имя модуля совпадает с именем интерфейса (именно имя модуля с именем интерфейса, а не наоборот) и интерфейс строится автоматически.
"Более гибко" - пожалуйста, можно думать о расширении этой схемы, это ВООБЩЕ НИКАК не фиксируется в языке. Это фиксируется в среде/рантайме.
Поскольку именно эта часть Оберонов сейчас активно развивается - пожалуйста, давайте высказывать предложения и идеи и обсуждать.
Можно подумать о способах множественной загрузки модулей, можно подумать о более строгом механизме создания/хранения/обработки спецификаций модулей. Можно позаимствовать что-то из Ады (например, ASIS). Если вы думаете, что "оберонщики все это отметают", то ничего подобного. У нас в планах на развитие ББ все это стоит на очереди. Но очередь имеет более и менее приоритетные задачи.

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


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

Отлично, избавились от терминологической путаницы. Теперь давайте определимся снова, имя ЧЕГО должно использоваться для квалификации импорта?
ASU считает, что это должно быть имя интерфейса, а не модуля, так получается гораздо  более гибко. Присоединяюсь.


Сергей, скажите пожалуйста, в какой раз мне нужно объяснять, что в Обероне квалифицируется интерфейс (DEFINITION) модуля? Мне нужно перечислить номера сообщений, где об этом четко говорилось?


Не надо так резко. Проблема на самом деле существует.
Оберон предполагает автоматическую сборку описания интерфейса по ГОТОВОЙ РЕАЛИЗАЦИИ - только звездочки поставить.
Тогда как описание интерфейса должно предшествовать разработке модуля.


Этот вопрос я достаточно подробно разбирал при обсуждении идеи верификатора. Это было 10 апреля. См. »сообщение 3788« и %3789

Сообщение ASU, инициировавшее данную дискуссию, датируется 13 апреля и имеет номер »сообщение 3856«.

Мне надо что-то говорить о причинно-следственной связи или это излишне?




<<<... | 4046—4037 | 4036—4027 | 4026—4017 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 223


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

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

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

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

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

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