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


Для "нанопрограммирования" это лишнее.


Для чего?


А если ран-тайм (система Oberon в миниатюре) будет занимать, скажем, 100-300 Кбайт, а лежащий поверх него слой поддержки активных документов -- около 50 Кбайт? Тогда как?


Тогда "активные документы" будут толстыми :) Чудес не бывает. Либо толстый фрэймворк, в котором есть все, либо толстая программа, которая все свое носит с собой.


Если цена вопроса -- "вес", то он равен примерно паре-тройке TTF-шрифтов.


Это пока все домыслы или можешь показать пример? Активный документ весом 350кб, у которого все на борту? Причем желательно, чтобы функционал такого документа выглядил недосягаемым для какой-нибудь обычной HTML-страницы :) Ну и трудоемкость создания такого документа приемлемая (а то я и на C++ могу наколбасить вьюер в 4кб exe :)

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

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

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

То есть, поддерживается инкапсуляция, как то и требуется в современной парадигме модульного программирования... Это хорошо.

Да, хорошо. :)
К сожалению, не вижу равноценных средств инкапсуляции в иных подходах.
В том числе -- в Вашем (возможно, пока не вижу).

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

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

Ну зачем же половину? Для "нанопрограммирования" это лишнее. А если ран-тайм (система Oberon в миниатюре) будет занимать, скажем, 100-300 Кбайт, а лежащий поверх него слой поддержки активных документов -- около 50 Кбайт? Тогда как? Если цена вопроса -- "вес", то он равен примерно паре-тройке TTF-шрифтов.

Ответ на »сообщение 4220« (Как слышно? Приём!)
___________________________


Суть в размере вьюера по сравнению с документом ...
Предполагается, что он будет на порядки меньше Excel,


Суть в размере "активного" составляющего документа. В моем случае - это программа на VBA. Он была маленькой :) Размер "фрэймворка" (будь то офис, браузер с поддержкой джава-скрипта, Flash-плеер, JRE или .NET) волнует мало, потому что устанавливается один раз. "Вьюер от оберона", даже если он не потащит за собой половину Блэкбокса, тоже не имеет смысла распространять каждый раз полностью.

Ответ на »сообщение 4221« (MS)
___________________________
Вы не против, что в принципе получаем одна системообразующая сущность (СЭ), котора имеет одинаковую структуру (входы, выход, знания) на разных уровнях?
Нет, я не против... :)
Могут быть и одинаковые интерфейсы на разных уровнях... (полиморфизм допустим не только у классов, состоящих в связях наследования).

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


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

Существет СЭ который обладает знанием о том как решается некоторая задача (и имеет места под входные и выходные разъёмы, т.е. имее три слоя: область входОВ, область выходА (одного)) и область "знания что делать".
После его инициализации он обращается к некому общему хранилищю ВСЕХ имеющихся элементов (как простейших, так и СЭ), и выбирает там подходящие по разъёмам для входОВ и выходА.
Если происходит разрыв связи (отключение элемента на любом уровне), то СЭ, от которого произошло отключение, опять обращается в хранилище для поиска замены отключённому элементу

(Входы и выход - интерфесы для соединения с элементами)

Вы не против, что в принципе получаем одна системообразующая сущность (СЭ), котора имеет одинаковую структуру (входы, выход, знания) на разных уровнях?

Ответ на »сообщение 4215« (pepper)
___________________________
>>> Я такое еще в универе делал на Excel и VBA.
Дык и на Дельфи можно и много ещё на чём ...
Суть в размере вьюера по сравнению с документом ...
Предполагается, что он будет на порядки меньше Excel,
свободен для распространения, быстр в работе.
Скорость работы Excel ...
И потом ... за слово "Бейсик" здесь можно схлопотать :)

Размер оценочно указывался ... вот только залило всё болото -
глубоко нырять.

Ответ на »сообщение 4217« (MS)
___________________________
Имеется два вида элементов - "простые" (процедуры, переменные объекты ...) и системообразующие.
Системообрзующие элементы (СЭ) имеют только диспетчер, который обеспечивает связь с элементами нижестоящими в иерахии с одной стороны, и СЭ более высокого уровня с другой.
Системообразующий элемент – это и есть элемент верхнего уровня.

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

Т.е. иерархия : "простой" элемент ->СЭ -> ... ->СЭ
Да.

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

Ответ на »сообщение 4217« (MS)

Каждый элемент объявляет свой контракт.
Системообразующий элемент (СЭ) объеденят контракты нижестоящих элементов и на базе зарегистрированных контрактов осуществляет взаимодействие между этими контрактами и объявляет свой контакт для вышестоящего СЭ.

Ответ на »сообщение 4192« (ASU)
___________________________
Есть более простые и понятные термины: системы и ее элементы. Элементы могут быть простыми или сами являться системами. Иерархия выстраивается от простых элементов до...
Хорошие системы имеют очень небольшое количество уровней.
Тогда такой вариант:
Имеется два вида элементов - "простые" (процедуры, переменные объекты ...) и системообразующие.
Системообрзующие элементы (СЭ) имеют только диспетчер, который обеспечивает связь с элементами нижестоящими в иерахии с одной стороны, и СЭ более высокого уровня с другой.
Каждый элементы в образованной иерархии связан только с одним СЭ, взаимодействие между элементами одного уровня происходит исключительно через диспетчер СЭ, с которым они связаны.
Т.е. иерархия : "простой" элемент ->СЭ -> ... ->СЭ