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

Если же B не импортирует А непосредственно, а получает указатель на Inc, то ситуация усложняется. 1 - счетчик = 0; 2 - значение счетчика сохраняется; 3 - значение счетчика = 0;
В первом случае мы имеем висячий указатель на Inc.

Интересное уточнение.

Вы эти все варианты проверяли в BlackBox? А в ETH Oberon? Или вообще не проверяли, а просто знаете по опыту работы?

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

Ответ на »сообщение 4038« (Руслан Богатырев)
___________________________
А в Обероне нельзя достичь этого эффекта при помощи композиции объектов?
Достичь можно по-разному. Оберон -- это же конструктор. Здесь два аспекта:
1. Нюансы поддержки нескольких иерархий через границы модулей
2. Что есть контекст и зачем вообще нужен?
ОО-системы характеризуются децентрализацией управления, при этом данные, отвечающие в совокупности за состояния системы и ее частей (элементов), "размазываются" во всем объектам.
Вот так вот! «Децентрализация управления», «состояния системы», все в... одной «размазне». Не сочтите за «апломб», но... сие не есть «вершина человеческой мысли». Если в любой системе с обратной связью на M – узлах исполнительных устройств установлено N – различных датчиков, информация с которых поступает в единый обрабатывающий центр. В центре информация обрабатывается, анализируется и, на ее основании вырабатывается некое регулирующее воздействие. Сие есть децентрализация или централизация? Что мешает построить «объектную» модель такой системы? Если быть ближе к семантической основе вопроса... то централизация/децентрализация – это характеристики распределения полномочий по принятию решений/распределению ответственности. В объектной системе никто не принуждает (и не рекомендует!) делать «ответственным» каждый объект.

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

Требуется неким образом выявлять из всех возможных состояний сущностей ту квинтэссенцию, которая и может формировать состояние системы (или отдельного ее компонента, если мы говорим о компонентах). Если объекты работают безусловно (без знания о состоянии системы/компонента), то это создает определенные проблемы.
Угу... Я бы даже добавил, что эти проблемы весьма серьезны, но к системам они отношения вообще не имеют. Понимаете, тому, кто не желает видеть, очки не помеха...

Далее. Регулирование переходов из состояния в состояние должно в идеале осуществляться не на уровне языка реализации, а выше -- на уровне проекта (архитектуры) или макета (формальной модели). Должен быть контроль корректности отображения модели на язык реализации хотя бы на уровне таких вещей как компоненты и состояния.
Господа, здесь должны быть аплодисменты! Причем стоя... Ибо нам дают возможность осознать, что архитектура системы на языке реализации невыразима!.. Ура! Господа! Оркестр, прошу «Прощание славянки»... :)
(Хотя с другой стороны, это косвенное подтверждение того, о чем я говорил раньше, создать большую систему на Oberon... увы... Сергей Губанов, finite la comedy... Вы получили окончательный ответ от ответственного лица. Я же говорил, что ответ Вас разочарует, простите, Сергей, я честное слово, в этом не виноват...)

В общем-то, моя реплика относительно третьего параметра была вызвана обоими упомянутыми аспектами.
Спасибо. Достаточно.

PS. Руслан, я просил Вас не трогать системы. Помните? С другой стороны, Вы просили меня показать Вам Ваши промахи... Это дает мне некоторый шанс надеяться, что Вы простите меня... чем-нибудь не очень тяжелым... :)

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

Да мне-то понятно, а Сергею Губанову, видимо, нет.

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

Сочувствую, если это для Вас верх сложности.
Но, подождите-ка, из Ваших слов получается, что не существует языка, заточенного под программирование для Windows. Так? Следовательно, т.к. Windows -- модульная система (опять же Ваши слова), и даже на Oberon'ах писать под неё программы сложно, то Oberon -- одновременно модульный и не модульный язык? Так?

Да не терроризируйте вы Губанова. Думаю, и так уже понятно, что модульность системы напрямую не связана с модульностью языка реализации (точнее, с тем, имеет ли он конструкцию модуля и позволяет ли ее имитировать).

Наличие модулей в языке просто способствует построению модульных систем.

Ответ на »сообщение 4037« (info21)
___________________________
Я прошу прощенья, но тут руководство меня мягко пожурило:
- во первых поставлена задача писать без грамматических ошибок,
- во вторых и длинный список изменений/улучшений и подробное обьяснение почему то или иное плохо и как нам хотелось бы это изменить конечно существует, но существует также и проект Droplet, цель которого создание среды разработки и выполнения программ на языке Oberon/Oberon-2 (не Component Pascal) и было бы преждевременно и не корректнокритиковать существующий продукт (Blackbox) пока конкурирующего продукта еще нет.

Касательно же двух моих замечаний, то разьяснения следующие:
- при собственном закрытом формате исходного модуля и документации мы приобретаем по сути три  вещи - возможность выполнения команд отмеченных маркером/"коммандером", гиперссылки и возможность раскраски модуля (я имею в виду постоянную раскраску, а не выделение цветом ключевых слов). При этом маркера команд не нужны вообще - я восемь часов в день выполняю команды содержащиеся в тексте и никак не отмеченные, причем могу выполнять команды содержащиеся в plain-ascii файле. Гиперссылки не нужны в исходных модулях, а для документации может быть использован любой формат, поддерживающий их, например html. Постоянное раскрашивание представляется мне крайне полезным, но на этом же форуме было охаяно в пользу выделения цветом ключевых слов, что кстати есть функция редактора, а не текста.
Что мы проигрываем я писал - возможность использования инструментов третьих сторон. Тут все очевидно - не можем например использовать существующие средства контроля версий, spell checker и так далее.
- по поводу мешанины с внутренним и внешним именами модуля (внутреннее имя это имя заданное в операторе MODULE, а внешнее имя это имя файла исходного модуля) могу сказать, что практика, когда внутреннее имя есть конкатенация имени подсистемы и внешнего имени, файл имеет простое внешнее имя, а вызов модуля в IMPORT идет опять по внутреннему имени запутывает пользователя и идет вразрез с существовавшей практикой когда внутреннее имя всегда превалирует над внешним. (Отмечено не только мной но и зарубежными пользователями Blackbox имевшими опыт работы с системами Oberon). Более естественной представляется схемакогда внешнее и внутреннее имена модуля совпадают, а вызов иде по квалифицированному имени типа IMPORT Forms:Cmds. Если думать дальше, то и без квалификатора можно обойтись, но это длинный разговор.

Нехлый пост получился, не хуже трактата о сущности модулей.

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

Сочувствую, если это для Вас верх сложности.
Но, подождите-ка, из Ваших слов получается, что не существует языка, заточенного под программирование для Windows. Так? Следовательно, т.к. Windows -- модульная система (опять же Ваши слова), и даже на Oberon'ах писать под неё программы сложно, то Oberon -- одновременно модульный и не модульный язык? Так?

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

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

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


1. Выгружается модуль A и загружается снова. Счетчик в A равен нулю?
2. Выгружается модуль B и загружается снова. Счетчик в A равен нулю?
3. Выгружается модуль A, затем модуль B, загружается модуль A, затем модуль B. Счетчик в A равен нулю?

Если же B не импортирует А непосредственно, а получает указатель на Inc, то ситуация усложняется. 1 - счетчик = 0; 2 - значение счетчика сохраняется; 3 - значение счетчика = 0;
В первом случае мы имеем висячий указатель на Inc.

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


1. Выгружается модуль A и загружается снова. Счетчик в A равен нулю?
2. Выгружается модуль B и загружается снова. Счетчик в A равен нулю?
3. Выгружается модуль A, затем модуль B, загружается модуль A, затем модуль B. Счетчик в A равен нулю?

Если B импортирует A (командой IMPORT), то A не может быть выгружен раньше, чем B.
В свете этого 1 - невозможно; 2 - счетчик остается неизменным; 3 - невозможно.

Ответ на »сообщение 4040« (Руслан Богатырев)
___________________________
Угу... и называться все это будет Unix.