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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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


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

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

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

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


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

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

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

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

<<<... | 3896—3887 | 3886—3877 | 3876—3867 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 238


№ 3886   15-04-2007 03:23 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3885« (AVC)
___________________________

Главное. "Слабые" связи тоже требуют определенного механизма.
В Обероне такой механизм есть.
Он Вам не нравится.
Но взамен Вы предлагаете некий неопределенный механизм, с передачей всей ответственности системному загрузчику.
Остаются неясными:
1) механизм межмодульного контроля типов (этим отличается раздельная компиляция от независимой);
2) механизм разрешения конфликта имен.
 AVC


№ 3885   15-04-2007 03:05 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3882« (ASU)
___________________________

Речь о том, что прикладной программист не должен знать, что и откуда будет импортироваться и куда экспортироваться. Он не должен(!) на уровне модуля прописывать системную логику, те самые «слабые» связи. «Слабые» связи не должны быть компетенцией языка разработки. Это задача системного линкера при статическом связывании или системного загрузчика при динамическом связывании.

Мы уже выяснили, что в Обероне ни список импорта, ни квалифицирующий импорт в принципе не препятствуют тому, чтобы "слабые" связи были перекоммутированы "на лету".

А что предлагаете Вы?
Не указывать, какие модули импортируются и не квалифицировать импортируемые идентификаторы в надежде на системный загрузчик?
Он Вам "налинкует", ага... :) Вы просто получите кучу ошибок в итоге.
В свое время мы разбирали, что одна из функций модуля -- определить пространство имен.
Причем само пространство имен (без модульности) не гарантирует от ошибок (рассматривался, в частности, учебный пример Свердлова на C#).

Другой момент. Вы предлагаете предоставить "слабые" связи системному загрузчику (при динамическом связывании).
Вопрос на засыпку: а как компилятор будет осуществлять межмодульный контроль типов до того как в дело вступит системный загрузчик?
 AVC


№ 3884   15-04-2007 02:58 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3870« (Илья Ермаков)
___________________________
Все верно, в Оберонах большая часть межмодульных связей и декларируется в терминах интерфейсов.
«Часть»?.. Хорошо сказано... возможно по поводу строгого аскетизма и правильности...

Есть модули - основные "строительные блоки" для системы. Модули коммутируются между собой различными способами. И статический импорт - только один, самый простой и прямолинейный из этих способов.
Совершенно верно.

Другие связи выстраиваются динамически на основе разъемов. И разновидностей таких разъемов весьма много.
Здорово!..

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

В модульных не-ОО языках (Модула, старая Ада) такие разъемы могли быть только процедурными (обычный callback).
В ОО-модульных языках появляются объектные разъемы.

Хм... Разъемы – это интерфейсы? Я правильно Вас понимаю? Что означает процедурный или объектный интерфейс?.. Любая сущность (модуль, в том числе) применяются тогда, когда они полезны, то есть, обладают некими возможностями, которые необходимы и, при этом, могут предъявлять свои потребности, которые необходимо удовлетворить. Возможности и потребности – это декларация... Любому, кто использует интерфейс безразлична его реализация (тем более, что она может меняться... сегодня через USB пишем на флэш, завтра на жесткий диск, а послезавтра... интерфейс остался неизменным, а его потребители с обоих сторон могут меняться без потери работоспособности системы).

Эти разъемы могут использоваться по разным схемам.
1) Объектный callback-разъем.

Хм... Это о чем?.. Callback – это обратный вызов, это будильник, который меня будит...

2) Разъем подключения реализации (в Блэкбоксе называется Hook).
Вы отстаиваете полезность квалифицируемого импорта на уровне языка или среды?..

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

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

4) Инсталлируемые каталоги. "Лицевой" модуль сервиса определяет абстрактные интерфейсы для этого сервиса и предоставляет инсталлируемую точку доступа к фабрике объектов, реализующих эти интерфейсы. Модули реализации динамически инсталлируют фабрики в "лицевые" модули.
«Фабрика» – это элемент языка Оберон или RTL?

Замечу, что во всех этих схемах ООП является служебным механизмам, а не системообразующей схемой. В частности, не используется наследование реализации.
Это предмет гордости?.. С моей точки зрения... это серьезный минус... Любые системы, а открытые, тем более, имеют свою логику развития. И ООП удобный механизм реализации такого развития.

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

В частности, процедурные разъемы в исходной форме (как указатели на процедуру) в Блэкбоксе используются редко, чаще прибегают к символьной ссылке на процедуру (ведь модуль, к котором находится процедура, может быть перезагружен, и адрес процедуры изменится).
Илья, меня не интересуют реализации. Поверьте, я не первый год занимаюсь разработкой систем, и сам могу сделать любую необходимую мне реализацию. Здесь отстаивалась мысль, что квалифицированный импорт, который имеет место быть в языке Оберон, - это очень правильное, надежное и удобное решение. У меня есть сомнения относительно того, что подобные вещи в любом языке
а) необходимы;
б) полезны;
в) удобны.
Но не вижу смысла говорить в терминах: «нравится» или «не нравится». Ранее неоднократно утверждалось, что Оберон – хороший язык системного программирования. Покажите это на данном конкретном примере.


№ 3883   15-04-2007 02:31 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3882« (ASU)
___________________________

Здесь я удивлен... Нет, не тем, что «заклевали» (на форумах это обычное дело), а тем, что вы («оберонщики»)... считаете это важным. Мне пространно «ответили» Илья и Руслан, но... ответа так и не прозвучало...

Вообще-то знакомое выражение. Когда некий корреспондент задает вопрос интервьюируемому и получает некий ответ, то он нередко восклицает: "Ответа я не получил!" Да неужели? Ответ был представлен. Вот только ответ (форма, содержание) может не устраивать вопрошающего по тем или иным причинам.

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

Т.е. предлагаю вернуться к инициирующему »сообщение 3856« и подставить вместо Оберон другой "параметр". Мне бы того же хотелось... Может быть подскажите, как квалифицированный импорт сочетается с "системностью" Oberon?

После этого можно будет разобрать отличия/специфику Оберонов в данном контексте.


№ 3882   15-04-2007 02:20 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3874« (AVC)
___________________________
В программировании "сильные" и "слабые" связи как раз и находят свое выражение в модульности.
а) не только в модульности;
б) модульность обязана реализовывать «слабые» связи (т.е. я бы усилил Ваше высказывание).

Главное, это прямо соответствует принципам системного подхода.
Это выражение одного из основополагающих принципов системного подхода.

Слава Богу, хоть кто-то понимает эту потребность!
:)))

А то нас, бедных оберонщиков, прямо заклевали за то, что мы считаем это важным.
Здесь я удивлен... Нет, не тем, что «заклевали» (на форумах это обычное дело), а тем, что вы («оберонщики»)... считаете это важным. Мне пространно «ответили» Илья и Руслан, но... ответа так и не прозвучало...

По сути предлагаемых Обероном механизмов.
В Обероне экспорт модуля может использоваться как место коммутации.

Очень хорошо!..

Модуль экспортирует "гнездо" коммутации (процедурную переменную, указатель на фабричный объект и т.д.), система может "на лету" подключить туда ту или иную реализацию функциональности, загрузив дополнительный настроечный, "теневой" :) модуль, явно не импортируемый другими модулями. Благодаря такой организации, этот модуль может быть заменен на другой, после чего его можно даже просто выгрузить.
Замечательно!..

Возможно, обероновские механизмы модульности здесь несовершенны и могут быть улучшены.
Но они все же позволяют решать данную задачу, при сохранении простоты языка и программной архитектуры.

Хм... Простите за настойчивость, но... где же решение?.. Да, я согласен с тем, что в Обероне есть хорошие механизмы, но речь не о них. Речь о том, что прикладной программист не должен знать, что и откуда будет импортироваться и куда экспортироваться. Он не должен(!) на уровне модуля прописывать системную логику, те самые «слабые» связи. «Слабые» связи не должны быть компетенцией языка разработки. Это задача системного линкера при статическом связывании или системного загрузчика при динамическом связывании. Термин «системный», в данном случае, не означает принадлежности к ОС, но к любой, в том числе, и вновь создаваемой системе. Так почему Оберон предусматривает квалифицируемый импорт, а «оберонщики» столь настойчиво доказывают его необходимость и полезность? Мой вопрос был об этом.


№ 3881   14-04-2007 23:01 Ответить на это сообщение Ответить на это сообщение с цитированием
сообщение от модератора

Jack of Shadows, вы, возможно, не знаете, что в Королевстве появилась новая техническая возможность - бан участника (на время или навсегда). Но если вы будете и дальше переходить на личности и оскорблять своих оппонентов, то вам придётся познакомится с этим новшеством поближе.


№ 3880   14-04-2007 22:27 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3858« (Руслан Богатырев)
___________________________
>>>Хотелось бы понять, сколь это важно для языка.
Это упрощает синтаксис, а "соглашение по именованию" – побочный эффект


№ 3879   14-04-2007 18:24 Ответить на это сообщение Ответить на это сообщение с цитированием
Немного информации на тему "квалифицирующий импорт".

Вот цитата из совершенно необероновского курса "Основы объектно-ориентированного проектирования":

Всякое общение двух модулей A и B между собой должно быть очевидным и отражаться в тексте A и/или B.

http://www.intuit.ru/department/se/oopbases/3/8.html
 AVC


№ 3878   14-04-2007 17:45 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3877« (AVC)
___________________________

Пытаясь "докопаться до основ" :) , сформулирую так: полуабстрактные классы (и, следовательно, наследование реализации) в Обероне/КП вводятся там, где одна абстракция разбивается на два интерфейса (или более).
Некоторые возможные причины такого разбиения абстракции называются в 3-й главе документации ББ ("Приемы проектирования").
 AVC


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

>>>Единственный случай, где наследование реализации используется - это framework с базовыми типами-заготовками, поведение которых можно расширять через наследование...

Действительно, типы-заготовки ("полуабстрактные" типы) часто встречаются во фреймворке.
Но все же это не единственное место, где они могут встречаться.
Как мне кажется, главная причина использования полуабстрактных типов (классов) -- необходимость введения системы взаимодействующих (двух и более) типов и упрятывания организации их взаимодействия от типов-наследников.
Такими взаимодействующими типами могут быть, например, контейнер и итератор, и т.д.
IMHO, именно на этот случай Шиперски сформулировал свой принцип "No Paranoia".
 AVC


<<<... | 3896—3887 | 3886—3877 | 3876—3867 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 238


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

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

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

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

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

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