Еще одно место обсуждения Оберона.

http://www.codecomments.com/Oberon/

Ответ на »сообщение 4507« (captain cobalt)

Капитан, OBJECT в АО ДАЛЕКО не "аналог" void* в Си/Си++.

В Си/Си++ - это просто некий указатель на всё равно что. Изначально никакой "нагрузки" на уровне системы он не несёт.
В АО OBJECT - "нагруженный" изначальными свойствами "механизьм" для поддержки ООП в языке и системе.
Да, он является "чистым" ссылочным типом, но использовать его в качестве аргумента функции не имеет смысла и не правильно: на OBJECT кончается "системный логический слой". Да вы знаете, что OBJECT - предок всех объектов. Но,и - только. После этого про само существование OBJECT как типа забудьте. Он просто - часть того механизма, которым обладает данная система, что бы вы смогли реализовывать ваше ООП-представление в ней. Не больше! "Настоящие" (корневые, родовые, абстрактные) типы - вот тот "материал", которго вы должны касаться. Забудьте про само существование OBJECT & (POINTER TO)RECORD END! Попробуйте так к этому относиться в своих проектах и они будут намного надёжнее и правильней разработаны.

Ответ на »сообщение 4507« (captain cobalt)
___________________________
Objects.Object # OBJECT в том понимании, которое вы стараетесь здесь отстоять...

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

Тогда попытка запихнуть в аргумент непотребство могла бы проверяться во время компиляции?
В Проверке нет смысла. Мы обявляем РОДОВОЙ тип обработчика. "Разбор типа" (конкретизация решения на реакцию в обработчике) реализуется в потомках...

Ответ на »сообщение 4507« (captain cobalt)
Теперь осталось отгадать одну загадку...?

Разгадка: динамическая расширяемость системы. Старые модули не надо будет каждый раз  перекомпилировать при появлении новых типов сообщений. Старые обработчики просто будут игнорировать неизвестные им сообщения.

Ответ на »сообщение 4506« (Владимир Лось)
___________________________
В исходниках Оберона, того который "Ten Years After", уйма аргументов типа Objects.Object

Заметьте, что АРГУМЕНТЫ в приведённых вами функциях, являются именно такого типа, корневых классов. Это сделано просто исходя из того, что ДРУГИЕ типы сущностей не предусмотрены для анализа и обработки.

Теперь осталось отгадать одну загадку: если предусмотрена обработка только одного типа, почему именно этот тип не заявлен для аргумента? Тогда попытка запихнуть в аргумент непотребство могла бы проверяться во время компиляции?

Ответ на »сообщение 4504« (captain cobalt)
___________________________
Получилось несколько раньше ответить... :о)

Я кажется понял, в чём у вас проблема.
На мой взгляд, вы путаете абстрактный тип-родоначальник отдельного (под)дерева в лесу иерархий классов в какой-либо предметной области и абстрактный тип OBJECT, как НОСИТЕЛЬ реализации одного из аспектов ООП в языке.

Ведь посмотрите, даже в приведённых вами примерах, НЕТ чистого использования OBJECT или RECORD END. Я поэтому и удивился и засомневался (даже "пробежался" по январским  исходникам ББ – думал, что-то поменялось... :о) ), когда вы сказали, что в АО это "сплошь и рядом". Нет там этого. Да, в принципе, - и БЫТЬ НЕ МОЖЕТ. Потому, что в этом просто НЕТ СМЫСЛА С ТОЧКИ ЗРЕНИЯ ГРАМОТНОЙ РАЗРАБОТКИ АРХИТЕКТУР КОНКРЕТНЫХ СИСТЕМ (ПРИЛОЖЕНИЙ).

В каждом из ваших примеров, приведён АБСТРАКТНЫЙ (может быть КОРНЕВОЙ) КЛАСС каждой из иерархий. Именно в этом классе ЗАЯВЛЕНЫ некие функциональности. Но их реализация сделана в потомках. Данный же корневой класс – явно выделенный "ярлык", "название", "способ обозначения принадлежности ко множеству"... В нём даже не обязательно что-то должно определяться.
Заметьте, что АРГУМЕНТЫ в приведённых вами функциях, являются именно такого типа, корневых классов. Это сделано просто исходя из того, что ДРУГИЕ типы сущностей не предусмотрены для анализа и обработки. Сами эти процедуры – являются обычно заявленными для некоего ОБОБЩЁННОГО способа работы с ОБОБЩЁННЫМ типом. Именно с данным типом, а не с каким-то иным. А вот конкретизация того, как обращаются к переданному в эти процедуры экземпляру (или что от него требуют), происходит или в потомках, или в таких же по сигнатуре процедурах...

Ответ на »сообщение 4504« (captain cobalt)
___________________________
Уважаемый коллега,
из вашего постинга, я вижу, что процесс зашёл слишком далеко и слишком "не в ту степь", и просто "парой слов" тут не "отбрешешься"... :о) Ближайшими часами-днями, я ОБЯЗАТЕЛЬНО отвечу на ваш постинг.

Строку приведите, пжлст. Именно, что вот так вот прямо и было написано буквами.

О том что абстрактные объекты - "это хорошо". Цитата из "Project Oberon":
A. Ten Years After: From Objects to Components
In practice, the design of the Oberon runtime model as described in Chapters 3, 4 and 5 proved to be basically flawless and sustainable. However, later developments gradually revealed some unused potential. The main shortcoming was the absence of a generic object type that would serve as an abstract root of the entire Oberon object hierarchy. As a remedy, we later added a module called Objects and two abstract types Object and Library, from that we then derived some previously independent types via type extension. Figure A.1 depicts the resulting type hierarchy. This simple extension of the Oberon kernel had an amazingly beneficial effect, and it allowed us to develop a substantial evolution of the original Oberon system, including
• A generic persistence mechanism for objects
• A generalized notion of text as sequence of arbitrary objects
• A fully hierarchic component framework
• An advanced graphical user interface (GUI) called Gadgets

О том что такое OBJECT "и с чем его едят". Цитата из диссера Мюллера:
The built-in type OBJECT is the implied base type of all objects. A variable of this type can store a reference to any object instance. It is usually used in combination with type tests and type guards, to implement generic object operations.

Вы меня, канечна за назойливость извините, не покажите ли примерчик? с указанием, из какого файла это взято... Что бы именно примерно так:

Вот:

MODULE AosProcessors;
...
TYPE
...
Message* = POINTER TO RECORD END;
...
END AosProcessors.


MODULE AosMemCache;

IMPORT ..., AosProcessors;
...
TYPE
SetCacheMessage = POINTER TO RECORD (AosProcessors.Message)
physAdr, size, type: LONGINT;
res: ARRAY AosBoot.MaxCPU OF LONGINT
END;
...
PROCEDURE HandleSetCacheProperties(id: LONGINT; VAR state: AosInterrupts.State; msg: AosProcessors.Message);
BEGIN
WITH msg: SetCacheMessage DO
...
LocalSetCacheProperties(msg.physAdr, msg.size, msg.type, msg.res[id])
END
END HandleSetCacheProperties;
...
END AosMemCache.

"Именно примерно так" ? (с)

Ответ на »сообщение 4502« (captain cobalt)
___________________________
Кому и из каких источников известно? :о)
Любому из материалов проекта Bluebottle/Active Oberon. ;)
Строку приведите, пжлст. Именно, что вот так вот прямо и было написано буквами.
Запишите на будущее... :о)
Это лишнее. ;)
Ну, мало ли... :о)
Говоря строго, тип OBJECT – НЕ указатель.
Тогда так: OBJECT - это ссылочный тип данных.
Теплее... :о)
И он - совсем НЕ указатель на ПРОИЗВОЛЬНЫЙ тип...
И совместим с любым другим произвольным объявленным через OBJECT объектным типом.
Ну слава Богу, значит всё-таки не ПРОИЗВОЛЬНЫЙ... Вы уточняйте вот так всегда, а то по контексту вы сначала за объектную "фривольницу" пишете и сразу вот так вот про OBJECT...
Вы меня пугаете ещё больше! Это шо ж, вы все аргументы-объекты в функциях (процедурах) объявляете как OBJECT, а потом, после приведения/проверки, начинаете им пользоваться? :о)
Далеко не все.
И не только аргументы, но и результаты и модульные переменные и локальные переменные процедур.
И не только OBJECT но и RECORD END
И не в "голом" виде а символьным синонимом для типа.
Кроме шуток, именно таких приёмчиков сколько угодно в официальном коде: имеется аргумент и ему тут же делается WITH.
Вы меня, канечна за назойливость извините, не покажите ли примерчик? с указанием, из какого файла это взято... Что бы именно примерно так:

any_var: OBJECT;
...
any_var := ... Или как аргумент функции...
...
WITH any_var: TAnyType DO
...
?
Ну надо же выяснить "маленькие неясности". ;)
Ничё себе "маленькие"!

Кому и из каких источников известно? :о)

Любому из материалов проекта Bluebottle/Active Oberon. ;)

Запишите на будущее... :о)

Это лишнее. ;)

Говоря строго, тип OBJECT – НЕ указатель.

Тогда так: OBJECT - это ссылочный тип данных.

И он - совсем НЕ указатель на ПРОИЗВОЛЬНЫЙ тип...

И совместим с любым другим произвольным объявленным через OBJECT объектным типом.

Вы меня пугаете ещё больше! Это шо ж, вы все аргументы-объекты в функциях (процедурах) объявляете как OBJECT, а потом, после приведения/проверки, начинаете им пользоваться? :о)

Далеко не все.

И не только аргументы, но и результаты и модульные переменные и локальные переменные процедур.

И не только OBJECT но и RECORD END

И не в "голом" виде а символьным синонимом для типа.

Кроме шуток, именно таких приёмчиков сколько угодно в официальном коде: имеется аргумент и ему тут же делается WITH. Причём в большинстве случаев только с одним вариантом. Фактически, таким образом имитируется ENUM, которого в Обероне нет, а SET "жирно будет".

Вы знаете, я что-то начинают терять убеждённость в необходимости дальнейшего обсуждения...

Ну надо же выяснить "маленькие неясности". ;)