Ответ на »сообщение 4274« (ASU)
___________________________


Контракт с кем? Контракт (договор) предусматривает более одной стороны...

Это открытый контракт, подписанный с одной стороны (исполнителя).
С другой стороны (Заказчика) его может подписать любой, готовый выполнить объявленные в контракте условия

Ответ на »сообщение 4262« (Сергей Перовский)
___________________________

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

А если мы написали программу, которая крутиться в бесконечном цикле?
например

n:=1
while n<2 do
  n:=n+0
end

Случай конешно вырожденный, но блок-схему нарисовать проблем нет.
И если это не алгоритм то что?

Ответ на »сообщение 4282« (Руслан Богатырев)
___________________________

Другими словами, язык Оберон/КП не предусматривает на уровне компилятора контроль соответствия разных версий реализации тому или иному интерфейсу.

Кстати, в XDS-реализации Оберона-2 (он в смысле экспорта-импорта от классического Оберона не отличается) сохранена схема Модулы-2. Это удобно еще и потому, что позволяет использовать оба языка одновременно (Модула-2 лучше Оберона подходит для низкоуровневых вещей).

Ответ на »сообщение 4259« (AVC)
___________________________
Мультиязычность систем может иметь один конкретный недостаток: недостаток надежности.
Хм?.. Вообще-то... строго наоборот... Возможно, Вы рассуждаете с позиций использования языков на одном уровне. Получается мешанина, которую трудно поддерживать, а не то что развивать. И надежность у такой конструкции... действительно вызывает большие сомнения. Но, я же говорил о том, что каждый язык (средство) должны использоваться на том уровне, где они максимально эффективны (и для написания, и для сопровождения, и для развития). Вы же не станете отрицать, что есть области, где функциональные языки или языки логического программирования позволяют проще и красивее решать задачи, по сравнению императивными языками. И если на каждом уровне вместо использования ложка-грабли-молотка (универсального инструмента) применять адекватные средства разработки, то надежность от этого только выиграет. Согласны?

В Обероне архитектура призвана поддерживать расширяемость системы (в принципе -- неограниченную).
Любимое Вами "буйство жизни". :)
Нет... Это не любимое мной... Мы слишком различно (как я понимаю) воспринимаем мир... Посмотрите за окно. Что Вы видите? Солнце светит, белые облака на голубом небе, девушки удивительно красивые... «Буйство жизни», одним словом... В Обероне «буйство жизни» - это делай (на уровне модулей) все что хочешь... захотел импортировать – импортируй, захотел экспортировать – экспортируй (вдруг кому-то зачем-то сгодится!)... Анархия... За моим окном... все не так... Все, что там есть – электроны, протоны и нейтроны... все остальное величайшее искусство (многоуровневой) композиции основанное на простых, но строгих законах. И свою задачу мы, наверное, видим различно... для Вас (надеюсь я ошибаюсь) важно повторить многообразие, для меня... освоить искусство композиции... :)

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

Цель была не в том, чтобы создать один конкретный программный комплекс, а в том, чтобы создать систему, способную к расширению.
... то есть, постепенному добавлению все новых элементов... нет, красивых девушек... так не... создать. IMHO. :)

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

Они занимались системным программированием (как оно обычно понимается, т.е. созданием программной архитектуры), а Вы -- созданием прикладной программной системы.
Хм?.. Я уже пообещал создать отдельную тему и там рассмотрю... не прикладной пример, если не будет возражений, разумеется.

Ответ на »сообщение 4279« (Антон Григорьев)
___________________________

Понятно, что при подмене модуля линкер проверит соответствие модуля B интерфейсу A и, если обнаружится несоответствие, выдаст ошибку. Но можно ли эту проверку осуществить на этапе компиляции?

В этом и есть отличие схем экспорта-импорта Модулы-2 и Оберона. В Модуле-2 интерфейс (он называется DEFINITION MODULE) -- это полностью самостоятельная вещь, создаваемая программистом НЕЗАВИСИМО от реализации (IMPLEMENTATION MODULE). В Обероне произошла "свертка", которая решила одни проблемы, но за счет порождения других (так обычно и происходит).

Подробно я разбирал этот вопрос здесь:
»сообщение 3788«
»сообщение 3789«
»сообщение 3800«

Другими словами, язык Оберон/КП не предусматривает на уровне компилятора контроль соответствия разных версий реализации тому или иному интерфейсу. Это можно сделать лишь косвенно, что не есть хорошо. Эту проблему можно решить относительно безболезненно (имея в виду схему Модулы-2 и контроль со стороны верификатора).

Ответ на »сообщение 4280« (Сергей Перовский)
___________________________

Каждый участник ДОЛЖЕН именовать свое творение по своему - иначе очень сложно разбираться в вариантах.

Он должен свое творение положить в конвертик, на котором проставляется шифр (или реальное имя) идентифицирующее участника конкурса.

Различие реализаций под один интерфейс -- это версионирование. Безотносительно того, делает это один и тот же разработчик (последовательно) или разные группы разработчиков (асинхронно).

Поэтому НЕ ДАВАТЬ использовать файловую систему для различия реализаций не слишком удачная идея.

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

Ответ на »сообщение 4273« (Руслан Богатырев)
___________________________
>>>По-другому названный модуль -- это следствие двух вещей:
Или двадцати двух :)
Например я описал интерфейс и объявил конкурс на его реализацию :)
Каждый участник ДОЛЖЕН именовать свое творение по своему - иначе очень сложно разбираться в вариантах. Тестирующая программа должна подключать по очереди все реализации и проводить их проверку.
>>>разработчику лень использовать средства управления версиями и он для имитации этого применяет файловую систему.
Фраза построена осуждающе, но средства управления версиями далеко не всегда предпочтительнее файловой системы-- это вопрос желания/хотения и конкретной ситуации.
Поэтому НЕ ДАВАТЬ использовать файловую систему для различия реализаций не слишком удачная идея.

Ответ на »сообщение 4273« (Руслан Богатырев)
___________________________

Модульный подход, реализованный в языке Оберон/КП, предсматривает обращение из модуля к интерфейсу (давайте это где-нибудь напишем большими буквами и повесим плакат). Реализации Оберона/КП (Oberon System, BlackBox) наглядно демонстрируют, что добиться динамической подмены реализации под заданный и зафиксированный интерфейс, это не только не проблема -- это основа упомянутых расширяемых систем. Но для этого нет надобности вводить динамику соответствия "интерфейс-реализация" на уровне языка. Достаточно их просто разделить, что и сделано в языке (DEFINITION -- отдельно, MODULE -- отдельно).

Когда есть интерфейс и реализация, возможны четыре варианта отношений:
1. один-к-одному (один интерфейс -- одна реализация)
2. один-ко-многим
3. многие-к-одному
4. многие-ко-многим

Вирт (Модула-2, Оберон) пошел по первому пути. Этот путь позволяет называть интерфейс так же, как и реализацию (одинаковым именем), но не запрещает подменять реализации в динамике выполнения.

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

Ответ на »сообщение 4253« (Takun)
___________________________
Возьмем в качестве учебного примера Интернет (раз уж компилятор не погодился ;-) ). Уровни у него есть (если исходить из модели в виде стека протоколов). Объектов полно, слабых связей тоже. Практически все можно выключить или заменить без потери его системности.
Надеюсь никто не скажет, что Интернет маленькая система?
Спрашивается, в каком месте у него над-уровень?
Хороший вопрос... Посмотрите стандарт OSI... :)

Логично предположить, что сверху. Но среди многочисленных прикладных служб, как то: Web, FTP, Email, Emule, DNS, Usenet и т.п., и т.д. я не вижу ничего, что бы являлось для Интернета определяющим. Да, без DNS было бы тяжко, но если заменить его альтернативным решением, то Интернет Интернетом быть не перестанет.
А Вы не припомните, кто инициировал запрос о том, что «управление Интернетом» не плохо было бы передать в ведение международной организации... Чем все это закончилось и почему... Теперь «над-уровень» стал понятнее?..

1) Логика системы сосредоточена не в над-уровне, а в связующем уровне, в характеристиках связей стистемы.
Логика системы... Логика системы присутствует на каждом из уровней... И каждый уровень... заглядывая вверх, говорит: «Вот она... какая Система!»... И только самый верхний уровень, посматривая вниз... понимает, что система – это все это сооружение вместе с ним... родимым.

2) Логика системы определяет лишь некоторые свойства системы (определяет некоторый класс систем?).
Правильно, но не совсем точно... Свойства системы – это проекция интерфейса более высокого (над-системного) уровня на данную сущность. Свойств «вообще» не бывает, свойство – это результат взаимодействия. Так вот, (в чем же неточность)... над-система определяет «интерфейс», которому должна соответствовать система, вместо со своей логикой.

Ответ на »сообщение 4276« (Илья Ермаков)
___________________________

Хорошо :-) Не контракт. Бланк контракта, который модуль затем подписывает с каждым, кто хочет его использовать :-)

Публичная оферта.