OberonCore

В свете того, что "все пути приводят к HandleMsg":
http://obertone.ru/doku.php?id=bbextendnohost

стоит, думаю, обдумать этот вопрос

Если любой абстрактный тип каркаса имеет HandleMsg, то никаких проблем с расширяемостью нет.
А пока в базовой поставке этого нет, то проблемы с расширяемостью будут постоянные.

Т.е. стоит аккуратно подумать о том, либо:
1) Во все типы каркасы, где этого ещё нет (Stores, Files) ввести HandleMsg - в базовой сборке.
2) Либо вообще ввести единый базовый тип Object с таким HandleMsg.

Сообщения это штука хорошая, но я бы еще предложил рассмотреть вместо наследования агрегирование.
То есть не заставляем всех перейти на общего предка, а просто предлагаем деталь с хэндлом.
Правда сразу возникает проблема наследования и переопределения метода хэндла. Но тут можно выбрать оберон-вэй с процедурным полем хэндлера вместо объекта и метода.

В каком смысле "деталь"? )

Для Stores и наследников кто-то предлагал ввести доменную шину (.HandleDomainMsg), было бы достаточно.
Для всяких Files, Ports, Windows необходимость сообщений назрела. Но иметь общий предок для File и Window это какой-то оверхед.
А при создании новых системных абстрактных интерфейсов можно вообще исключить методы, все кроме хэндлера.


Вспоминая вот эту тему viewtopic.php?f=47&t=4175
Возможна ли реализация более удобного сервиса деталей без модификации ядра? Ну или с расширением функций ядра в виде плагина.

И, товарищи, не зацикливайтесь на объектах.

А какой Ваш вариант?

Да это всё узкоспециальная вещь )

Предлагал и продолжаю.

Еще можно сделать необязательный метод любому объекту, типа FINALIZE только HANDLE.
Тогда базовый Object не нужен.

Да, но это изменение языка уже и компилятора.

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

Это будет очень дорого обходиться...

В принципе, можно обойтись модификацией ядра и загрузчика, чтобы загрузчик находил процедуру с условленным именем - и потом в Kernel.Type добавлял указатель на неё в какое-то спец. поле (в виртуальную таблицу по минус-адресам от Type уже не получится, там "вотчина" компилятора).

Но какая-то уже больно рантаймо-специфичная семантика уже, не хотелось бы.

Завязываясь на какие-либо функции ядра, нужно не забывать, что ядро --- это конкретная платформозависимая реализация. А не нечто перманентное в долгосрочных перспективах.

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

Ядро должно обеспечить определённый функционал. Способ реализации и скрытый интерфейс это никак не фиксирует.

Да, но в случае финализаторов - это поддержка семантики, закреплённой в языке.

Ну для решения одной задачи "добавить HANDLE" достаточно того, что ядро уже имеет возможность пройтись по таблице методов. Не нужно менять язык. И зависимости от хоста (ядра) мы уже обсуждали. Осталось только получить возможность найти в нужный момент нужный метод конкретного объекта, и вызвать его.

У финализаторов в ядре есть преимущество, конечно. Они вычисляются при создании объекта, и хранятся в списке.

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

Я просто не сильно понимаю на этом уровне

Когда Вы пишите v.Do, то компилятор шьёт код:
полезть по указателю v-4
взять оттуда тег типа - адрес Kernel.Type
пойти на -N от этого адреса (где виртуальная таблица методов)

Вот этот -N известен на этапе компиляции (т.к. интерфейс v статически известен, в символьном файле).
И он прошивается в код константой.