Ответ на »сообщение 4235« (ASU)
___________________________
Александр, я понимаю существование проблемы взаимодействия модулей в больших системах. Я не понимаю Вашего утрирования этой проблемы... Конструкция модулей и межмодульных связей воспроизводит соотв. концепции железной техники. Автомобиль, например, является системой? Почему прямое обращение двигателя к карбюратору не противоречит системности, а прямое обращение модуля HTTP-сервера к модулю работы с файловой системой ей противоречит? И в том, и в другом случае модуль является свободно заменяемым черным ящиком, взаимодействие происходит по специфицированному интерфейсу.

Ответ на »сообщение 4228« (MS)
___________________________
А чем в этом случае отличается модуль Оберона от СЭ?
Создаётся модуль - хранилище, в котором имеется информация о всех загруженных модулях. Этот модуль (один) импортируется во все другие модули, в каждом из которых имеется диспетчер, который обеспечивает связь с диспетчером, вышестоящем модулем и нижестоящими модулями по особому каналу.
Единственно, что, простейшие элементы должны также находится в модулях, но их всё равно надо гденить хранить (хотябы в файлах :-)), да и писанины будет ненамного больше.
Вы считаете, что эту схему нельзя создать на ассемблере? Тогда чем же ЯВУ отличаются от ассемблеров? Согласитесь, что подобная постановка вопроса не совсем корректна.

Ответ на »сообщение 4225« (AVC)
___________________________
Насколько я понимаю то, что Вы говорите, главное различие между "системным" и "обероновским" подходом все-таки заключается в основных структурных единицах.
Нет, не только... Основное различие на концептуальном уровне, все остальное - следствия...

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

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

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

>>> я и на C++ могу наколбасить вьюер в 4кб exe
Вот это и назвали нанопрограммированием.
Интересно, Вы на С++ можете 4кб (пусть с минимумом функций), а на ББ 300 Кб нельзя?

>>> Я всего лишь выясняю цену вопроса
Размер вьюера уже оценивали постов так за 600 раньше.
Но у меня Dual-up и ошибки вываливаются - найти терпения не хватило.
Помню, что мало - меньше 300 кил. Можете вытащить?

Поясню для Ваших контрпримеров - вьюер свободно распространяемый,
без инсталляции, небольшой и в силу монолитности с документом подходит
к нему на 100%.
Просто кликаешь по нему и работаешь.
Вообще-то это программа. И расширение будет exe (если не для Web).
Но стандартно генерируемая и являющая собой активный документ.

VB - тут лицензия и размер больше и инсталляции требует.

Размер фреймвока.
Конкретный случай - схема, созданная в AutoCAD 2007.
Приехал к клиенту - посмотреть не начем.
Есть бесплатные утилиты, но требуют регистрации на сайте со всякой тягомотиной.
Купили в ларьке пиратский CD, чтобы только посмотреть.
Не ставится. Купили в другом - то же. Вылетает при установке дот нета на этапе
поддержки языков. Местные АСУшники бились с версиями дот нета ...
Потом пришёл на наше счастье начальник ПТО с ноутбуком - посмотрели
и выдернули в старый формат.
Вот такие танталовы муки с толстыми фреймвоками. Ну да не я один такой.

Другое дело - нажал и смотри. Тем более вьюер, вроде как кроссплатформенный.

P.S.
>>> ... Имя ей - безопасность.
"Я боюсь спать - наверно я трус.
Денег нет. Зато есть пригородный блюз".

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

Ответ на »сообщение 4230« (Сергей Губанов)
А на форуме oberoncore.ru как зарегистрироваться кто-нибудь знает?
Напишите на bb16 собака oberoncore.ru.
Сейчас мы авторегистрацию временно отключили - из-за спамеров, администратор изобретает новую версию регистрационной формы :-)

Ответ на »сообщение 4230« (Сергей Губанов)
___________________________

Описания форматов находятся в папке \Dev\Spec

Спасибо, нашел. Однако не сильно понятно. Вернее, совсем непонятно. :)

А на форуме oberoncore.ru как зарегистрироваться кто-нибудь знает?

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

А спецификацию формата .odc где можно найти? С удовольствием бы изучил.
Или из исходников выковыривать предлагается?

Описания форматов находятся в папке \Dev\Spec

А спецификацию формата .odc где можно найти? С удовольствием бы изучил.
Или из исходников выковыривать предлагается?

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


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

А чем в этом случае отличается модуль Оберона от СЭ?

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

Единственно, что, простейшие элементы должны также находится в модулях, но их всё равно надо гденить хранить (хотябы в файлах :-)), да и писанины будет ненамного больше.

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

Это пока все домыслы или можешь показать пример?

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

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