Дерево - это один вход, много выходов. Не надо арбитража многих входящих. Всё просто.

А вот интересно, каковы виды разруливания многих входящих?
Вопрос дерево - сеть упирается именно в это.

1) Блокирующие - отказ в доступе с уведомлением и далее с повторной попыткой.
2) Постановка в очередь и её обслуживание.
3) Распараллеливание - передача на обслуживание другому блоку с такими же функциями.
Но потом всё равно сводить, но уже обработанный сигнал.
4) Вынести в железо с аналоговым сумматором по многим каналам. Для частной функции.
Вот уж модуль, данный нам в ощущениях :)
5) Введение ранжирования входящих по срочности обслуживания (к 1 и 2).

>>> У меня, например, постоянно получается "широкая композиция" с "глубоким наследованием" :)

То есть наследование от ООП, а композиция - рукоделие в виде надстройки?
Как говорили "логика отдельно". Как ООП поддерживает эту самую композицию?

По поводу примера задачи. Начинаю понимать Jackа, когда с него трясли пример задачи, на которой станет понятно преимущество Лиспа.
Задача нужна сложная с тонкостями и ньюансами, и наглядности не получается.
Если придумывать пример из головы - слишком абстрактно и без отягчающих подробностей на слом которых всё и нацелено.

Ответ на »сообщение 4736« (Axcel)
___________________________
>>>В частности, есть у меня подозрение, что "широкая композиция" может быть предпочтительнее "глубокого наследования" (сам правда пока не пробовал).
Может быть, а может не быть.
Все зависит от задачи.
У меня, например, постоянно получается "широкая композиция" с "глубоким наследованием" :)
Я, собственно, только об этом и говорю: утверждаете, что новый метод (подход, инструмент, идеология, концепция) лучше старого - сформулируйте четко, по каким критериям проводилось сравнение и на каких задачах.
Никто из нас не имеет опыта работы во всех областях программирования. Поэтому, то, что одному кажется фантастическим прорывом, у другого вызывает только вежливый интерес, а у третьего ощущение движения назад.

Ясненько :) Спасиб...

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

Моя мысль плавно протекла из "травяной" темы про "русскую" ОС в сюда.
Отсюда вполне логичный вопрос: Есть ли Оберон для Линукс? А IDE?
Мы в Орле 4 месяца уже гоняем под Линуксом обычную виндовую версию Блэкбокса - и в ВУЗе, и в школах, и в фирме, и дома...
Пока линуксовую не добьем, живем так - и нормально, надо сказать, живем :-)

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

Моя мысль плавно протекла из "травяной" темы про "русскую" ОС в сюда.
Отсюда вполне логичный вопрос: Есть ли Оберон для Линукс? А IDE?

Оберон для Линукс есть. [url]http://www.excelsior-usa.com/xds.html[/url]
Работае в Linux (линковка через gcc) и, после некоторых изменений, во FreeBSD (добрые люди уже сделали порт для оного).
С IDE сложнее. Есть на Windows, но это не тот продукт, в котором хочется работать. Сам я работаю в Far'e с Colorer'ом. Лучше редактора пока не видел.

Моя мысль плавно протекла из "травяной" темы про "русскую" ОС в сюда.
Отсюда вполне логичный вопрос: Есть ли Оберон для Линукс? А IDE?

В дополнение к »сообщение 4738« (Владимир Лось)
___________________________
Кстати, именно "где-то рядом" и Инферно с Лимбо находятся по идеологии формализации обмена.
И (ВНИМАНИЕ!) подобные же вещи (блокирующий обмен между компонентами) ужЕ и на уровень железяк переходит! Мур анонсировал свой SEAforth24A - чип с 24-мя ядрами (6х4), в котором ядра обмениваются друш с другом точно на таком же принципе, что и модули в QNX и Minix - блокирующий обмен сообщениями (типа рандеву), но в сифорте ожидание подобно конструкции alt { ... } Лимбо (практически прямая железячная реализация! :о) )

Ответ на »сообщение 4734« (Axcel)
___________________________
При этом никаких специфических показаний для подобной схемы у нас нет, просто так удобнее, надежнее. Но ведь это же и есть истинная модульность.
Всё равно до истинной модульности, как в QNX и Minix3 там далеко. Почему именно в этой оси "истинная модульность"? Потому, что кроме формализации и явного выражения понятия "модуль" на уровне ужЕ ОСи (экая невидаль! :о) ), там ещё и формализовано средство обмена информацией между модулями. Это именно то, к чему (на более высоком уровне) сейчас дошли в Зонноне и Композите! Правда в QNX и Minix3 обмено по таким "формализованным средствам" самый простой и "низкоуровневый" (блоки байтовых данных) и отсутствует слежение за правильностью поддержки протоколов общающимися сторонами.
Представляете, как классно Композита "ложится" реализацией над такми осями?!!! (микроядро + строгое разделение адрессных пространств + обмен сообщениями)

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

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

Может, мне и кажется, но впечатление такое, что С.Перовский все время говорит о проблемах, которые замечательно решаются в Оберонах, как наоборот о проблемах Оберона.

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

Сиё глубокое подозрение широко распространено :-)