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

Просто в качестве рефлексии: здесь к модулям применен тот же прием (инсталляция коммутирующего объекта), что и в О-1 к записям.

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

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

По поводу "коммутации".
В недавней статье Ильи Ермакова "Некоторые идеи архитектуры Оберон-систем" в качестве отдельного пункта названы инсталлируемые каталоги объектов (ББ-директории).
Просто в качестве рефлексии: здесь к модулям применен тот же прием (инсталляция коммутирующего объекта), что и в О-1 к записям.

Ответ на »сообщение 2551« (Jack Of Shadows)
___________________________

В case каждое ответвление либо прерывается break либо перетекает в следующее.
Таким образом переставьте местами ответвления не прерываемые break и получите совершенно разный код.
Последовательность имеет значение.

В Обероне, как и в Модуле-2 (да и как в классическом Паскале) ветки CASE никуда не перетекают. Они изолированы друг от друга. Считайте, что после каждой стоит всегда неявный break.

Ответ на »сообщение 2547« (Илья Ермаков)
___________________________

Есть над чем поразмыслить. Итог: требуется большой объем работ, однако результат того стоит.

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

Ответ на »сообщение 2537« (AVC)
___________________________
В case каждое ответвление либо прерывается break либо перетекает в следующее.
Таким образом переставьте местами ответвления не прерываемые break и получите совершенно разный код.
Последовательность имеет значение.
Хотя может в обероне и не так. Может у вас нет break в case. Но тут уже как видите в каждом императивном языке своя специфика.

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

Руслан, что именно Вы понимаете под "философией" Оберон-мышления?

Коротко ответить не получится. Но мышление - это не перечисление нескольких принципов или фич. "Материя" более высокого порядка. Здесь придется затронуть вопросы культуры программирования и субкультуры языков, противостояния американской и европейской культур и причин "порабощения" европейской культуры. Оберон-мышление, Оберон-философия - это нечто большее, чем Оберон-технологии. А потому - более ценное.

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

Ответ на »сообщение 2547« (Илья Ермаков)
___________________________

И хорошо бы в этом направлении, да все упирается в наличие общей платформы выполнения для различных диалектов.

Давайте попробуем н порассуждать. Какие реализации Оберонов из существующих наиболее практичны? На мой взгляд, КП/BlackBox (в первую очередь), XDS и OO2C (последние два - и миграция в Си-мир). Какие реализации перспективны с точки зрения мэйнтрим-тенденций (Java, .NET)? Наверное, КП/GPCP (Eclipse) и Zonnon (как для .NET, так и для Eclipse). Какие интересны в плане исследований в сфере мультипрограммирования и различных real-time приложений? Прежде всего, Active Oberon/Bluebottle.

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

Вопрос: можно ли в КП/BlackBox выделить такое подмножество (вроде Си-подмножества в C++; как языка, так и внеязыковых средств, включая библиотеки), которые позволили бы осуществить относительно простую миграцию полностью или частично наработанных решений в другие Обероны или даже другие языковые платформы? Чем-то это может напоминать кросс-программирование (когда на целевой платформе иметь инструментарий нереально или дорого, а проще все создавать для нее на другой). Вот это обсуждать и даже реализовывать, на мой взгляд, было бы интересно и, что самое главное, полезно в практическом плане (да и в плане выживания Оберонов).

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

Да в общем, ОТ, на мой взгляд, много менее ценна, нежели "философия" Оберон-мышления. Но готовы ли мы это здесь глубоко обсуждать?


Руслан, что именно Вы понимаете под "философией" Оберон-мышления?
В статье "Оберон. Коротко о главном" Вы писали:
В Обероне есть три кита, на которые опирается его философия (см. "От Modula к Oberon"):

  1. процедурные типы (процедура как тип, коммутация функций);
  2. модули (единица компиляции и загрузки, основа построения компонентов);
  3. расширение комбинированного типа (расширяемые записи, альтернатива ООП и основа динамической эволюции систем).

Я понимаю (возможно, неверно; потому и спрашиваю) это так.
В языках ООП эти ортогональные составляющие смешаны (в классах и методах), в Обероне -- нет.
Насколько большое значение это имеет?
Мне это не совсем ясно, хотя могу привести пример, где я совершил (очень) глупую проектную ошибку, которую бы не сделал, если бы был к тому времени знаком с Обероном(-1).
В одной из программ реального времени запланированные задачи размещались в (приоритетной) очереди.
Иногда задача не могла проделать всю работу за отведенное время, тогда она ставила себя в очередь повторно.
(Здесь немного похоже на способ исполнения задач в Оберон-системе.)
У меня был базовый абстрактный класс "Действие" (Action), все задачи были его производными.
Иногда над одними и теми же данными требовалось произвести несколько последовательных действий (в частности, так осуществлялись навигационные вычисления, слишком "тяжелые", чтобы их можно было сделать "за один присест"). Разные действия (естественно) выполнялись разными методами. И вот здесь я, не подумав, и совершил ошибку. Я порождал для следующего действия объект другого класса, а затем передавал ему привязку к перечисляемым данным в виде указателей.
А если бы подумал (или знал об Обероне-1), то мог бы использовать тот же самый объект, просто переинсталлировав процедурную переменную "сделай" (act()).
Конечно, это с моей стороны просто глупость, но одна из причин -- автоматизм в применении стандартного ООП.

Ответ на »сообщение 2545« (Руслан Богатырев)
___________________________
Понятная практическая мотивация. Но обратите внимание: ОТ вроде бы должна роднить Обероны и позволять практикам применять тот язык-диалект или инструментарий (ориентированный на ОТ), который больше всего подходит для конкретного проекта. На деле же Обероны разрознены. Лебедь, рак и щука...
Так может, в этом направлении народную мысль двинуть?

И хорошо бы в этом направлении, да все упирается в наличие общей платформы выполнения для различных диалектов.
Общая платформа может быть а) создана с нуля б) развита из одной из реализаций в) создана интеграцией каких-либо двух (вряд ли большего) числа реализаций.
Первый вариант пока неподъемен.
Если смотреть на второй/третий, то встает задача общего объектного представления и необходимость реанимировать и творчески переосмысливать представление Франца.
По поводу варианта б) и в) - если иметь в виду не Native OS, а просто общую платформу/рантайм (что для практиков, кстати, более необходимо, нежели ОС), то уже есть из чего выбирать. Три ветки - классический Оберон и два BB (BlueBottle & BlackBox).
Однако в каждой из веток есть что-то, чего нет в других.
Классический Оберон - это плюс минимального первого Оберона в качестве базового языка, эдакого "общего знаменателя", ассемблера для всех остальных диалектов.
BlueBottle - это параллельное программирование и хороший графический интерфейс.
BlackBox - это легкая интеграция с Windows-приложениями, надежность и обкатанность на реальных промышленных проектах плюс хорошая идея GUI на составных документах (коих в BlueBottle я вообще не увидел - или плохо смотрел?).

Есть над чем поразмыслить.

Итог: требуется большой объем работ, однако результат того стоит. Для того, чтобы этот объем работ таки был выполнен, нужен реальный, крупный, долгосрочный промышленный проект, под который будет создана такая общая платформа.
Чтобы такой супер-проект возник, необходимо продвигать Оберон в любых реализациях для конкретных выполнимых проектов. Отсюда и возникает "зацикленность" на конкретных реализациях - пока приходится заниматься именно этим. Как только на горизонте появится проект, под который тот же BlackBox окажется тесноватым, интеграция Оберонов в нечто единое и качественно более мощное пойдет естественным образом.