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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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


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

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

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

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


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

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

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

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

<<<... | 3956—3947 | 3946—3937 | 3936—3927 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 232


№ 3946   Удалено модератором


№ 3945   Удалено модератором


№ 3944   16-04-2007 00:41 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3934« (Сергей Перовский)
___________________________

И аргументы кажутся разумными: соответствие между объявленными интерфейсами и реализующими их модулями должны быть известны системе и не могут быть известны использующими модулями.

В цепочке "клиент --> сущность --> интерфейс --> реализация" соответствие "интерфейс --> реализация" не известно клиенту и известно системе. Это справедливо и не только для языка Оберон.

Возможность построить модуль для реализации нескольких ранее объявленых интерфейсов тоже заметный плюс.

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

Если так беспокоит проблематика конфигурирования модулей в Обероне, то такая проблема есть, она обсуждалась. Могут быть разные подходы к ее решению. Почему обязательно они должны лежать на уровне того же самого языка реализации? В частности, этот вопрос находится в прямой сфере интересов т.н. кластерно-модульного программирования:
»сообщение 3590«
»сообщение 3128«
»сообщение 3168«
»сообщение 3097«
»сообщение 3114«


№ 3943   16-04-2007 00:04 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3935« (AVC)
___________________________
А именно: квалифицирующий импорт видится ему неуместным элементом "сильной" связи там, где должна господствовать "слабая".
Разве не так?..

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

В качестве же Арины Родионовны здесь выступает вовсе не Деннис Ритчи, а Богданов-Малиновский (с примкнувшим к нему Людвигом фон Берталанфи).
Это будет трудная охота; Антон Григорьев даже опасается, что для многих она станет последней... :)

Хорошо... бы...


№ 3942   15-04-2007 23:45 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3934« (Сергей Перовский)
___________________________
Хотя ASU и открещивается от COM технологии, его рассуждениям соответствует прежде всего она.
??? А интерфейсы CORBA не примеряли? Вроде бы тоже... соответствуют... Но по секрету, шепотом... скажу... что в этих реализациях интерфейсов... системных «плюшек» очень много...

СОМ технология во многом не совершенна, но этот принцип реализован очень здраво.
Без этого принципа... говорить было бы не о чем...

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

Не надо, Сергей... Я Вас умоляю... :)

Возможность объектного интерфейса это, конечно, плюс Оберону, но это скорее недоработки СОМ технологии.
(и кто бы еще объяснил этот «объектный интерфейс»)... Если исходить из сути, то... интерфейс не может быть ничем иным, как декларацией... Как же выглядит объектная декларация?.. (и зачем она вообще нужна?)


№ 3941   15-04-2007 23:39 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3927« (Илья Ермаков)
___________________________

Но тогда становится бессмысленным Ваш вопрос: "Почему Вы утверждаете, что Оберон удобен для системного программирования?" - да про системное программирование в Вашем смысле рассуждения и не велись.

Системный программист такую вольную трактовку термина своей сферы компетенции вряд ли бы дал. :) Значит, речь о специалисте иной квалификации.

Кстати, а с чего мы вдруг решили, что программная система должна подчиняться воззрениям философа-экономиста Богданова-Малиновского и биолога Людвига фон Берталанфи? (Что же мы тогда забыли про Н.И.Бухарина?) Потому что называется "система"? Хорошо. Давайте назовем сие "сооружением" и обратимся в сферу строительного дела. Или там труды упомянутых ученых игнорируют?


№ 3940   15-04-2007 23:37 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3933« (AVC)
___________________________
Интерфейс (он же "междумордие" :) ) должен находиться где-то "между".
Но посмотрим внимательно, чьи сущности ("клиента" или "сервера") обыкновенно объявлены в интерфейсе. IMHO, это сущности (типы, константы, переменные, процедуры и т.д.), экспортируемые "сервером".
IMHO, если бы интерфейс что-то говорил о клиенте (я допускаю, что могут быть какие-то особые случаи), то это как раз был бы пример нарушения разделения системы на уровни, о котором Вы говорите. Ведь получается, что "сервер" обладает знанием о "клиенте", т.е. превышает уровень своей компетенции. Это уже не Богданов у нас получается, а Паркинсон. :)

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

Если брать Си/Си++, то эта задача в них и сейчас не решается.
Иначе попробуйте объяснить наличие стандартного пункта меню (и кнопки тулбара) "Rebuild all".
Зачем это надо, раз все под контролем?

Так я и F9 не сильно... уважаю... Собственно, с этого и началось... :)

>> Меня эти вопросы ничуть не затрудняют. Если позволите, то дам свой ответ: кнопочки находятся на интерфейсной панели телевизора или плиты. Кнопочка – это не горелка, кнопочка – это приспособление для человека (даже если находится на плите или поставляется с плитой). Попробуйте представить себе кнопку в виде иголки или столь тугую, что нормальный человек ее нажать не сможет. Представили? Хорошо... Надеюсь понятно?
А почему именно человек?

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

Может быть, у меня хозяйством занимается робот? :)
Вполне.

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

С системной точки зрения объект низшего уровня именно потому может использоваться в разных контекстах и разными "хозяевами", что (почти) ничего не предполагает об объектах высшего уровня.
слово «(почти)» совершенно излишне, без него Вы, собственно, подтвердили то, о чем я здесь говорю. Но, с Вашего позволения, я усилию это высказывание: объект высшего (над-) уровня тоже не предполагает ничего об объектах нижнего уровня... (включая и подуровни...).


№ 3939   15-04-2007 23:22 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3928« (Илья Ермаков)
___________________________
Александр, логика модуля и не включает как таковую межмодульную связь. Межмодульную связь отстраивает компоновщик (в Оберонах – динамический).
О! Золотые слова!!!

По факту, IMPORT A - это не установление связи с реализацией A, это всего лишь импорт некоторого интерфейса (лежашего, кстати, в отдельном файле - .sym), безонтосительно того, что там под этот интерфейс потом подставит загрузчик. Да, в в существующих реализациях Обероне имя импортированного интерфейса совпадает с именем модуля, так сделано для простоты, и в большинстве случаев более сложную схему нетрудно сэмулировать.
Угу... Значит возвращаемся к разговору о том, что ручками все можно сделать?.. Не убедили!..

Но нетрудно представить себе реализацию загрузчика, которой мы можем сказать, что для интерфейса A, используемого некоторым модулем C, нужно подгрузить в качестве реализации модуль AImplV12 или что-нибудь еще.
Мне нетрудно представить и прогулку по Марсу... Что из этого следует?..

Да, исходные тексты не разбиваются на два файла,
А кто об этом говорил? (только не надо показывать пальцем... в мою сторону... ошибетесь) :)

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

Таким образом, когда мы пишем в тексте модуля A.Do, то мы не подразумеваем модуль Do, а подразумеваем всего лишь обращение к некоторому внешнему модулю через интерфейс A. И чем тут плох квалифицированный импорт - это же импорт интерфейсов? Пусть наш модуль взаимодействует с окружающим миром по десятку интерфейсов, так разве не удобно всюду в его исходном тексте видеть, к какому из них он в том или ином случае обращается?
Я уже объяснял это... Понимаете у одного интерфейса может быть много реализаций... Подумайте над этим.


№ 3938   15-04-2007 23:15 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3927« (Илья Ермаков)
___________________________
>> Во-первых, мне непонятно, почему система ценностей человечества (или хотя бы научной его части) должно расходится с «нашей системой ценностей». Может быть Вы возьмете на себя труд, объяснить, чем общепринятое понятие «система» отличается от понятия «системы» в программировании.
Да потому что так устоялось десятилетиями...

Так, ведь, и я занимаюсь этим не первый год... :) Софистика начинается с лишения слов их смысла. А далее можно строить любые формально правильные, но совершенно бессмысленные утверждения и доказательства. Оно надо?

Может быть, повоюем против понятия "комплексное число", потому что непонятно, каким образом оно связано со словом "комплекс"? :-)
Очень даже прямая связь...

Прекрасно, никто не возражает против, того что лично Вы под этим понимаете нечто другое, нежели то, что описано в любом энциклопедическом словаре computer-science-направленности.
Но тогда становится бессмысленным Ваш вопрос: "Почему Вы утверждаете, что Оберон удобен для системного программирования?" - да про системное программирование в Вашем смысле рассуждения и не велись.

Понятно... Действительно, Вы правы, если под «системным программированием» понимать все что угодно, то говорить действительно не о чем...


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

А именно: квалифицирующий импорт видится ему неуместным элементом "сильной" связи там, где должна господствовать "слабая".

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

Если в языке используется сторонняя сущность, то у нее должно быть:
1) имя;
2) категория (константа, переменная, тип, процедура);
3) хотя бы приблизительный интерфейс (для процедур).

Берем крайность -- независимую компиляцию на уровне Фортрана (ассемблера).

Чем все это отличается от Delphi (автоматически и от Оберона) применительно к слабым связям?
1. Не указывается источник заимствования (вообще: ни в самом модуле, ни в точке использования).
2. Ослаблен контроль типов и версий (допустим, его просто нет).

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

Значит, остается только источник заимствования. Его отсутствие равносильно наличию одного-единственного источника с фиксированным именем (назовем просто LIBRARY). Проведем параллель с обычным call-центром. Есть некая организация, у которой либо один контактный телефон, либо несколько. В первом случае клиент не задумываясь (слабая связь, логическая коммутация) звонит по единственному номеру и физическая коммутация осуществляется call-центром (Если пользователь выбрал метод расчета, то подгружается соответствующий модуль, происходит привязка конкретной процедуры и... последующий вызов...).

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

Так в чем сомнения?

Приведу пример. Программа на ассемблере. Независимая компиляция. Использует системные вызовы (обращения к ОС, чтобы не было здесь недопонимания) вместо того, чтобы работать через абстрактно-вспомогательный уровень. Формально связь слабая. На деле -- более чем сильная. Так чем меряем силу натяжения?


Цитата из »сообщение 3889«:
А одна из заповедей системного проектирования – инкапсулируйте! Оставляйте снаружи только интерфейсы. Да, собственно, это давно уже не новость...

ASU, следуя мэйнстрим-трактовке, не делает различия между инкапсуляцией (encapsulation) и информационным сокрытием (information hiding). А такой взгляд -- более жесткая связь, нежели понимание (и применение) инкапсуляции как средства абстрагирования/комбинирования кода и данных безотносительно контроля области видимости (как это понималось в оригинале -- в CLU). В Обероне есть инкапсуляция как при отсутствии информационного сокрытия, так и вместе с ним -- у программиста есть выбор. Ну а интерфейсы -- через них и работают модули. Это недопонимание? Может, слово "интерфейс" понимается по-разному?

Смотрим »сообщение 3891«:
Мне бы не хотелось, чтобы слово «интерфейс» воспринималось узко, как COM-интерфейсы. Такой взгляд может стать причиной недоразумений. В данном контексте, я говорю о системных интерфейсах. Любая система имеет два или более уровней. Взаимодействие между уровнями происходит посредством объявленных интерфейсов, обязательных для обоих взаимодействующих уровней.

Каково же более широкое понимание интерфейса?
1. Интерфейс сам по себе (ему может соответствовать группа реализаций)?
2. Интерфейс декларирует сущности в минимальном варианте (только имена)?

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


<<<... | 3956—3947 | 3946—3937 | 3936—3927 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 232


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

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

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

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

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

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