Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 4286 22-04-2007 06:04 | |
Ответ на »сообщение 4274« (ASU)
___________________________
Контракт с кем? Контракт (договор) предусматривает более одной стороны...
Это открытый контракт, подписанный с одной стороны (исполнителя).
С другой стороны (Заказчика) его может подписать любой, готовый выполнить объявленные в контракте условия
№ 4285 22-04-2007 06:01 | |
Ответ на »сообщение 4262« (Сергей Перовский)
___________________________
По поводу различия программ и систем можно, наверно, использовать понятие алгоритма: вспомните, что в самом определении алгоритма заложена конечность числа шагов до достижения результата. Так вот, программы и процедуры (подпрограммы) имеют алгоритм, а система нет - она реагирует на внешние события выполнением тех или иных алгоритмов, но ее "основной цикл", вообще говоря, бесконечен.
А если мы написали программу, которая крутиться в бесконечном цикле?
например
n:=1
while n<2 do
n:=n+0
end
Случай конешно вырожденный, но блок-схему нарисовать проблем нет.
И если это не алгоритм то что?
№ 4284 22-04-2007 05:49 | |
Ответ на »сообщение 4282« (Руслан Богатырев)
___________________________
Другими словами, язык Оберон/КП не предусматривает на уровне компилятора контроль соответствия разных версий реализации тому или иному интерфейсу.
Кстати, в XDS- реализации Оберона-2 (он в смысле экспорта-импорта от классического Оберона не отличается) сохранена схема Модулы-2. Это удобно еще и потому, что позволяет использовать оба языка одновременно (Модула-2 лучше Оберона подходит для низкоуровневых вещей).
№ 4283 22-04-2007 05:37 | |
Ответ на »сообщение 4259« (AVC)
___________________________
Мультиязычность систем может иметь один конкретный недостаток: недостаток надежности.
Хм?.. Вообще-то... строго наоборот... Возможно, Вы рассуждаете с позиций использования языков на одном уровне. Получается мешанина, которую трудно поддерживать, а не то что развивать. И надежность у такой конструкции... действительно вызывает большие сомнения. Но, я же говорил о том, что каждый язык (средство) должны использоваться на том уровне, где они максимально эффективны (и для написания, и для сопровождения, и для развития). Вы же не станете отрицать, что есть области, где функциональные языки или языки логического программирования позволяют проще и красивее решать задачи, по сравнению императивными языками. И если на каждом уровне вместо использования ложка-грабли-молотка (универсального инструмента) применять адекватные средства разработки, то надежность от этого только выиграет. Согласны?
В Обероне архитектура призвана поддерживать расширяемость системы (в принципе -- неограниченную).
Любимое Вами "буйство жизни". :)
Нет... Это не любимое мной... Мы слишком различно (как я понимаю) воспринимаем мир... Посмотрите за окно. Что Вы видите? Солнце светит, белые облака на голубом небе, девушки удивительно красивые... «Буйство жизни», одним словом... В Обероне «буйство жизни» - это делай (на уровне модулей) все что хочешь... захотел импортировать – импортируй, захотел экспортировать – экспортируй (вдруг кому-то зачем-то сгодится!)... Анархия... За моим окном... все не так... Все, что там есть – электроны, протоны и нейтроны... все остальное величайшее искусство (многоуровневой) композиции основанное на простых, но строгих законах. И свою задачу мы, наверное, видим различно... для Вас (надеюсь я ошибаюсь) важно повторить многообразие, для меня... освоить искусство композиции... :)
Новые модули добавляются поверх старых, а старые могут расширить свой экспорт.
Вот... вот...
Цель была не в том, чтобы создать один конкретный программный комплекс, а в том, чтобы создать систему, способную к расширению.
... то есть, постепенному добавлению все новых элементов... нет, красивых девушек... так не... создать. IMHO. :)
Возможно, дело в том, что цели разработчиков Оберона не совпадали с Вашими целями?
Не думаю, что причина в этом... Они, в конечном итоге, тоже стремлись делать системы...
Они занимались системным программированием (как оно обычно понимается, т.е. созданием программной архитектуры), а Вы -- созданием прикладной программной системы.
Хм?.. Я уже пообещал создать отдельную тему и там рассмотрю... не прикладной пример, если не будет возражений, разумеется.
№ 4282 22-04-2007 05:33 | |
Ответ на »сообщение 4279« (Антон Григорьев)
___________________________
Понятно, что при подмене модуля линкер проверит соответствие модуля B интерфейсу A и, если обнаружится несоответствие, выдаст ошибку. Но можно ли эту проверку осуществить на этапе компиляции?
В этом и есть отличие схем экспорта-импорта Модулы-2 и Оберона. В Модуле-2 интерфейс (он называется DEFINITION MODULE) -- это полностью самостоятельная вещь, создаваемая программистом НЕЗАВИСИМО от реализации (IMPLEMENTATION MODULE). В Обероне произошла "свертка", которая решила одни проблемы, но за счет порождения других (так обычно и происходит).
Подробно я разбирал этот вопрос здесь:
»сообщение 3788«
»сообщение 3789«
»сообщение 3800«
Другими словами, язык Оберон/КП не предусматривает на уровне компилятора контроль соответствия разных версий реализации тому или иному интерфейсу. Это можно сделать лишь косвенно, что не есть хорошо. Эту проблему можно решить относительно безболезненно (имея в виду схему Модулы-2 и контроль со стороны верификатора).
№ 4281 22-04-2007 05:20 | |
Ответ на »сообщение 4280« (Сергей Перовский)
___________________________
Каждый участник ДОЛЖЕН именовать свое творение по своему - иначе очень сложно разбираться в вариантах.
Он должен свое творение положить в конвертик, на котором проставляется шифр (или реальное имя) идентифицирующее участника конкурса.
Различие реализаций под один интерфейс -- это версионирование. Безотносительно того, делает это один и тот же разработчик (последовательно) или разные группы разработчиков (асинхронно).
Поэтому НЕ ДАВАТЬ использовать файловую систему для различия реализаций не слишком удачная идея.
Кто мешает в отсутствие системы управления версиями размещать разные реализации одного интерфейса в разные каталоги файловой системы? Кто мешает называть по-разному файлы (в которых названия модулей остаются одинаковыми)? Кто мешает использовать конфигурирование сборки через файлы проекта, опции линкера/загрузчика и т.д. и т.п.?
№ 4280 22-04-2007 05:14 | |
Ответ на »сообщение 4273« (Руслан Богатырев)
___________________________
>>>По-другому названный модуль -- это следствие двух вещей:
Или двадцати двух :)
Например я описал интерфейс и объявил конкурс на его реализацию :)
Каждый участник ДОЛЖЕН именовать свое творение по своему - иначе очень сложно разбираться в вариантах. Тестирующая программа должна подключать по очереди все реализации и проводить их проверку.
>>>разработчику лень использовать средства управления версиями и он для имитации этого применяет файловую систему.
Фраза построена осуждающе, но средства управления версиями далеко не всегда предпочтительнее файловой системы-- это вопрос желания/хотения и конкретной ситуации.
Поэтому НЕ ДАВАТЬ использовать файловую систему для различия реализаций не слишком удачная идея.
№ 4279 22-04-2007 05:11 | |
Ответ на »сообщение 4273« (Руслан Богатырев)
___________________________
Модульный подход, реализованный в языке Оберон/КП, предсматривает обращение из модуля к интерфейсу (давайте это где-нибудь напишем большими буквами и повесим плакат). Реализации Оберона/КП (Oberon System, BlackBox) наглядно демонстрируют, что добиться динамической подмены реализации под заданный и зафиксированный интерфейс, это не только не проблема -- это основа упомянутых расширяемых систем. Но для этого нет надобности вводить динамику соответствия "интерфейс-реализация" на уровне языка. Достаточно их просто разделить, что и сделано в языке (DEFINITION -- отдельно, MODULE -- отдельно).
Когда есть интерфейс и реализация, возможны четыре варианта отношений:
1. один-к-одному (один интерфейс -- одна реализация)
2. один-ко-многим
3. многие-к-одному
4. многие-ко-многим
Вирт (Модула-2, Оберон) пошел по первому пути. Этот путь позволяет называть интерфейс так же, как и реализацию (одинаковым именем), но не запрещает подменять реализации в динамике выполнения.
В связи с этим возникает такой вопрос. Пусть у нас есть некоторый модуль A и созданный на его основе интерфейс (он же - DEFINITION). Теперь мы хотим создать модуль B, который будет реализовывать такой же интерфейс, что и A. Понятно, что при подмене модуля линкер проверит соответствие модуля B интерфейсу A и, если обнаружится несоответствие, выдаст ошибку. Но можно ли эту проверку осуществить на этапе компиляции? Как-то указать компилятору, что модуль B должен соответствовать интерфейсу A, и если обнаруживается несоответствие, чтобы этот модуль просто не компилировался. В описании Оберона я таких возможностей не увидел, а без них интерфейс не может считаться по-настоящему отчуждаемым.
№ 4278 22-04-2007 05:08 | |
Ответ на »сообщение 4253« (Takun)
___________________________
Возьмем в качестве учебного примера Интернет (раз уж компилятор не погодился ;-) ). Уровни у него есть (если исходить из модели в виде стека протоколов). Объектов полно, слабых связей тоже. Практически все можно выключить или заменить без потери его системности.
Надеюсь никто не скажет, что Интернет маленькая система?
Спрашивается, в каком месте у него над-уровень?
Хороший вопрос... Посмотрите стандарт OSI... :)
Логично предположить, что сверху. Но среди многочисленных прикладных служб, как то: Web, FTP, Email, Emule, DNS, Usenet и т.п., и т.д. я не вижу ничего, что бы являлось для Интернета определяющим. Да, без DNS было бы тяжко, но если заменить его альтернативным решением, то Интернет Интернетом быть не перестанет.
А Вы не припомните, кто инициировал запрос о том, что «управление Интернетом» не плохо было бы передать в ведение международной организации... Чем все это закончилось и почему... Теперь «над-уровень» стал понятнее?..
1) Логика системы сосредоточена не в над-уровне, а в связующем уровне, в характеристиках связей стистемы.
Логика системы... Логика системы присутствует на каждом из уровней... И каждый уровень... заглядывая вверх, говорит: «Вот она... какая Система!»... И только самый верхний уровень, посматривая вниз... понимает, что система – это все это сооружение вместе с ним... родимым.
2) Логика системы определяет лишь некоторые свойства системы (определяет некоторый класс систем?).
Правильно, но не совсем точно... Свойства системы – это проекция интерфейса более высокого (над-системного) уровня на данную сущность. Свойств «вообще» не бывает, свойство – это результат взаимодействия. Так вот, (в чем же неточность)... над-система определяет «интерфейс», которому должна соответствовать система, вместо со своей логикой.
№ 4277 22-04-2007 04:55 | |
Ответ на »сообщение 4276« (Илья Ермаков)
___________________________
Хорошо :-) Не контракт. Бланк контракта, который модуль затем подписывает с каждым, кто хочет его использовать :-)
Публичная оферта.
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|