Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 4236 21-04-2007 05:25 | |
Ответ на »сообщение 4235« (ASU)
___________________________
Александр, я понимаю существование проблемы взаимодействия модулей в больших системах. Я не понимаю Вашего утрирования этой проблемы... Конструкция модулей и межмодульных связей воспроизводит соотв. концепции железной техники. Автомобиль, например, является системой? Почему прямое обращение двигателя к карбюратору не противоречит системности, а прямое обращение модуля HTTP-сервера к модулю работы с файловой системой ей противоречит? И в том, и в другом случае модуль является свободно заменяемым черным ящиком, взаимодействие происходит по специфицированному интерфейсу.
№ 4235 21-04-2007 03:34 | |
Ответ на »сообщение 4228« (MS)
___________________________
А чем в этом случае отличается модуль Оберона от СЭ?
Создаётся модуль - хранилище, в котором имеется информация о всех загруженных модулях. Этот модуль (один) импортируется во все другие модули, в каждом из которых имеется диспетчер, который обеспечивает связь с диспетчером, вышестоящем модулем и нижестоящими модулями по особому каналу.
Единственно, что, простейшие элементы должны также находится в модулях, но их всё равно надо гденить хранить (хотябы в файлах :-)), да и писанины будет ненамного больше.
Вы считаете, что эту схему нельзя создать на ассемблере? Тогда чем же ЯВУ отличаются от ассемблеров? Согласитесь, что подобная постановка вопроса не совсем корректна.
№ 4234 21-04-2007 03:09 | |
Ответ на »сообщение 4225« (AVC)
___________________________
Насколько я понимаю то, что Вы говорите, главное различие между "системным" и "обероновским" подходом все-таки заключается в основных структурных единицах.
Нет, не только... Основное различие на концептуальном уровне, все остальное - следствия...
У Вас -- "уровни", в Обероне -- "модули".
Поэтому мне до сих пор кажется, что Вы главным образом критикуете модули.
Есть требования структурного программирования, и Оберон им соответствует, есть требования системного подхода, и Оберон им не соответствует. Модули я не критикую, а приветствую, благодаря им осмысливается и соблюдается инкапсуляция (хотя, к сожалению, не строго).
Трудность для меня заключается в том, что если обероновский подход я понимаю детально, то Ваш подход в деталях как раз пока неясен.
Как система поддерживает копии описаний, как решается конфликт имен (это вопрос вызван представлением, что "уровень" -- более крупная единица, чем "модуль").
Так уровни и... решают «конфликты имен»... Хорошо, давайте рассуждать. Предположим, что Вы, используя Оберон, пишите новый модуль. Из этого модуля Вы имеете возможность обратиться к любому другому модулю, который есть в Вашей среде разработки. Все, что Вам нужно, это указать нужный модуль в секции импорта своего нового модуля. И все, что экспортируется присоединяемым модулем, становится доступно Вашему новому модулю. Правильно?.. Модулей становится все больше и больше, мало того, у них появляются различные версии и реализации одних и тех же интерфейсных (экспортируемых) элементов (типов, подпрограмм и пр.). Соответственно, возникает проблема локализации (выделения подпространств имен) и арбитража при возникновении конфликтов. И вполне понятно, что у Вас возникает вопрос о том, какие же механизмы для разрешения конфликтов можно предложить с позиций системного подхода. Но «системность» состоит не в поисках универсальных «таблеток», а в понимании и устранении источника проблемы.
Как уже отмечалось ранее, уровень обладает собственным интерфейсом, то есть, имеет некое локальное «пространство имен». Элемент (например, модуль) взаимодействует с двумя уровнями. Для верхнего уровня он реализует какие-то интерфейсы, пользуясь при этом интерфейсами нижнего уровня. (Есть еще системные интерфейсы и служебные интерфейсы данного уровня, но я их сейчас не рассматриваю). Следовательно, существует очень небольшое количество «пространств имен», доступных элементу. И все, это совокупное пространство имен (а проще сказать, интерфейсы) доступно любому элементу (модулю) данного уровня и не требует оформления ни экспорта, ни импорта. Таким образом, деление системы по уровням решает задачу локализации (имен) и устраняет потенциальные конфликты.
К сожалению, не вижу равноценных средств инкапсуляции в иных подходах.
В том числе -- в Вашем (возможно, пока не вижу).
Что значит «равноценное» средство? Если в Обероне можно импортировать модуль, и обратиться к любой (экспортируемой данным модулем) подпрограмме или переменной, то, строго говоря, это уже нарушение (или не строгое соблюдение) инкапсуляции.
№ 4233 21-04-2007 02:20 | |
>>> я и на C++ могу наколбасить вьюер в 4кб exe
Вот это и назвали нанопрограммированием.
Интересно, Вы на С++ можете 4кб (пусть с минимумом функций), а на ББ 300 Кб нельзя?
>>> Я всего лишь выясняю цену вопроса
Размер вьюера уже оценивали постов так за 600 раньше.
Но у меня Dual-up и ошибки вываливаются - найти терпения не хватило.
Помню, что мало - меньше 300 кил. Можете вытащить?
Поясню для Ваших контрпримеров - вьюер свободно распространяемый,
без инсталляции, небольшой и в силу монолитности с документом подходит
к нему на 100%.
Просто кликаешь по нему и работаешь.
Вообще-то это программа. И расширение будет exe (если не для Web).
Но стандартно генерируемая и являющая собой активный документ.
VB - тут лицензия и размер больше и инсталляции требует.
Размер фреймвока.
Конкретный случай - схема, созданная в AutoCAD 2007.
Приехал к клиенту - посмотреть не начем.
Есть бесплатные утилиты, но требуют регистрации на сайте со всякой тягомотиной.
Купили в ларьке пиратский CD, чтобы только посмотреть.
Не ставится. Купили в другом - то же. Вылетает при установке дот нета на этапе
поддержки языков. Местные АСУшники бились с версиями дот нета ...
Потом пришёл на наше счастье начальник ПТО с ноутбуком - посмотрели
и выдернули в старый формат.
Вот такие танталовы муки с толстыми фреймвоками. Ну да не я один такой.
Другое дело - нажал и смотри. Тем более вьюер, вроде как кроссплатформенный.
P.S.
>>> ... Имя ей - безопасность.
"Я боюсь спать - наверно я трус.
Денег нет. Зато есть пригородный блюз".
№ 4232 20-04-2007 09:37 | |
Ответ на »сообщение 4231« (Mirage)
___________________________
Ответ на »сообщение 4230« (Сергей Губанов)
А на форуме oberoncore.ru как зарегистрироваться кто-нибудь знает?
Напишите на bb16 собака oberoncore.ru.
Сейчас мы авторегистрацию временно отключили - из-за спамеров, администратор изобретает новую версию регистрационной формы :-)
№ 4231 20-04-2007 09:16 | |
Ответ на »сообщение 4230« (Сергей Губанов)
___________________________
Описания форматов находятся в папке \Dev\Spec
Спасибо, нашел. Однако не сильно понятно. Вернее, совсем непонятно. :)
А на форуме oberoncore.ru как зарегистрироваться кто-нибудь знает?
№ 4230 20-04-2007 08:29 | |
Ответ на »сообщение 4229« (Mirage)
___________________________
А спецификацию формата .odc где можно найти? С удовольствием бы изучил.
Или из исходников выковыривать предлагается?
Описания форматов находятся в папке \Dev\Spec
№ 4229 20-04-2007 07:23 | |
А спецификацию формата .odc где можно найти? С удовольствием бы изучил.
Или из исходников выковыривать предлагается?
№ 4228 20-04-2007 07:23 | |
Ответ на »сообщение 4222« (ASU)
___________________________
Могут быть и одинаковые интерфейсы на разных уровнях... (полиморфизм допустим не только у классов, состоящих в связях наследования).
А чем в этом случае отличается модуль Оберона от СЭ?
Создаётся модуль - хранилище, в котором имеется информация о всех загруженных модулях. Этот модуль (один) импортируется во все другие модули, в каждом из которых имеется диспетчер, который обеспечивает связь с диспетчером, вышестоящем модулем и нижестоящими модулями по особому каналу.
Единственно, что, простейшие элементы должны также находится в модулях, но их всё равно надо гденить хранить (хотябы в файлах :-)), да и писанины будет ненамного больше.
№ 4227 20-04-2007 06:59 | |
Ответ на »сообщение 4226« (pepper)
___________________________
Это пока все домыслы или можешь показать пример?
Я всего лишь выясняю цену вопроса, отталкиваясь от некоторых своих оценок. Торгуюсь, так сказать. Хочу понять, какой объем разовой инъекции (внедрения ран-тайма) не напряжет и какой -- балласта к документу. Насчет чудес -- ран-тайм может быть полным (тогда в документе нет балласта), а может -- и неполным (оный присутствует).
Трудоемкость создания документа бессмысленно пока обсудать -- это вопрос инструментария, а не изготовленного с его помощью продукта в виде активного документа. Вопрос-то простой: все устраивает в мэйнстриме в этой области? Али нет? (На VB, кстати, можно сделать любую "бытовую" систему и распространен он ой как широко -- это к вопросу об аргументации).
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|