OberonCore

Чем делегат отличается от процедурного типа в Обероне, где сигнатура жестко зафиксирована как часть всей системы строгой типизации?

Что-то на эту тему похоронено в этой ветке: viewtopic.php?f=29&t=2125
хотелось бы просто выделить отдельно и ясно.

(Делегат = безопасный указатель на функцию, см. http://ru.wikipedia.org/wiki/%D0%94%D0% ... 0%B8%D0%B5))

Основное отличие по сравнению с PROCEDURE в КП - это возможность указать не только на процедуру, но и на метод конкретного объекта.

Т.е. если есть VAR do: DELEGATE (a, b, c: INTEGER); obj: SomeObject,
и у типа SomeObject есть связанная процедура (obj: SomeObject) Do (a, b, c: INTEGER),
то мы можем:

do := obj.Do;
...
а потом косвенно вызвать метод Do объекта obj:
do(a, b, c).

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

Моё мнение:
1) Концептуально штука простая и естественная. Если есть указатель на процедуру, то какая разница, кто обработает вызов - модуль или объект. На это всегда народ в спорах и упирает.
2) В реализации есть некоторые нюансы, но не особенные...
3) По значению своему не столь важно, чтобы разводить из мухи слона (как некоторые делали), но при массовых нововведениях в язык, когда-нибудь (например, при добавлении ЦД), я бы ввёл. Синтаксически просто сделал бы для всех PROCEDURE-переменных возможность указывать как на процедуры, так и на объект.метод. Похерив системную совместимость, пусть для системных указателей на процедуры на других языках будет флаг в SYSTEM.

===

Есть ещё отдельный нюанс - почему Оминк пометили процедурные переменные как устаревшие. Явно погорячились. Во-первых, без дальнейшей переделки языка всё равно от них не отказаться (конечно, они что-то планировали) - даже чтоб в итоге обратиться через Meta, нужно хотя бы временно получить проц. пер-ю. Во-вторых, лучше, видимо, сделать их более безопасными и общими (как-то решить проблему невалидности после выгрузки-перезагрузки модуля), плюнув на системную совместимость, как я написал выше.

в GPCP для jvm процедурные типы вообще отменили.

Да, после тех дебатов я писал примеры в Вики, как имитировать делегаты:
http://oberoncore.ru/wiki/blackbox/ex/delegates

В общем, синтаксический сахар, уменьшающий прозрачность реализации.

Делегат это не указатель на функцию, а это объект динамически размещаемый в куче и лишний раз почём зря напрягающий своей тушкой сборщик мусора. Внутри тушки делегатного объекта лежит указатель на таргетный объект "делегировавший" его и особым образом закодирована информация о методе таргетного объекта, который через этот делегат можно вызвать. Особым образом закодирована означает, что там не обязательно адрес начала кода процедуры ибо ежели процедуру ни разу не вызвали, то и машинный код для неё не генерировался (в дотнете JIT компиляция). И лишь только благодаря синтаксическому сахару языка C# делегат в исходном тексте программы может выглядеть (а может и не выглядеть) как "указатель на функцию". Однако это не мешает работать с ним (в случае необходимости) как с обыкновенным дотнетным объектом. Как у обычного объекта у него есть методы:
* получения таргетного объекта,
* получения объекта метаинформации о процедуре,
* и конечно все стандартные методы отнаследованные от базового System.Object.
Естественно он является GC-якорем для таргетного объекта. Ну ещё с помощью них можно мультикаст делать (ещё одна сладкая плюшка для ленивых) и вызывать в отдельном потоке взятом из пула потоков.

Делегаты применяются теми кому лень писать "много" исходного текста, а оверхед по памяти/скорости их не волнует, то есть когда приоритет отдаётся скорости написания исходного текста программы в ущерб её производительности.

Не эффективно. Делегаты можно реализовать так, что они не будут каждый раз размещаться в динамической памяти и напрягать сборщик мусора своими тушками. Уберите из описаний таргетный объект pl: Player и тогда объекты ссылочных типов PlayHandler и StopHandler можно будет сделать синглетонами и разместить в памяти лишь однажды. Таргетный объект правда каждый раз придётся подсовывать им отдельно, выглядеть будет не красиво, но зато без оверхеда по памяти на делегатную тушку.

А также в ущерб ясности реализации и, соответственно, главному качеству хорошей программы -- evolvability.

Ну, в Шарпе его сделали объектом, но это совершенно не обязательно.
Никто не мешает сделать value-значением. Просто копировать пару (адрес процедуры, указатель на объект).
Это справедливости ради.

(Так, в тему: мне были как-то интенсивно (по всей подсистеме) нужны указатели на процедуры, устойчивые к выгрузке модулей. А подсистема серверная, т.е. постоянно по имени раскапывать через Meta не будешь. Завёл тип RECORD с указателем на Kernel.Module и со смещением точки входа в процедуру от начала модуля. При разыменовании (procPtr.GetProc) проверяется, что модуль не выгружен (mod.refcnt >= 0), а если выгружен, то ищется его новая версия, выясняется имя процедуры по старой версии - и обновляется.)

А Вы досмотрите статью до конца. Там в конце выведен окончательный вариант без "тушек".

Должна быть виртуальная процедура. Для её вызова нужен указатель. Вот указатель на синглетон внуть структуры запихать можно. Это я про дотнет. А в Оберонах, да можно.