OberonCore

Это продолжение темы, выросшей из просьбы рассказать о процедурных переменных в Компонентном Паскале.

На первый взгляд, при наличии ООП они видятся избыточностью, потому что архитектурно любую процедурную переменную, как минимум, можно заменить объектом с одним методом. И как свидетельствуют разработчики, делается такое довольно часто даже несмотря на наличие процедурных переменных.
Естественно, ООП этим не ограничивается, но речь про избыточность процедурного типа при уже включённом в язык ООП, а не ООП как таковом, в том числе, и о потребности в нём строго в том виде, в котором оно представлено в КП.

Так как есть и обратное мнение, хотелось бы увидеть его в более конкретном выражении. Лучше всего в виде рабочего, но минимального кода. Это то, что позволяет лучше понимать суть в противовес растеканию слишком абстрактной мысли.


Дмитрий Викторович, я посмотрел Ваш доклад, но, к сожалению, так и не смог увидеть потребность в использования именно процедурных типов, а не ООП. Возможно, мы просто о разных темах? Как мне показалось, то, что Вы изложили, прекрасно оформляется в виде ООП. Если нет, было бы интересно рассмотреть такой код.

Вы знаете, свое понимание я изложил, наверное, ничего нового не добавлю. Вы вправе не соглашаться, конечно.

Есть одно внешнее обстоятельство: в интерфейсах к ОС и библиотекам встречаются процедурные параметры.

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

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

Согласно особенностям Oберона-2 методы - это всего лишь связанные процедуры, и невозможность их не связывать с точки зрения сложности ничего не устраняет, а кое-где даже добавляет. Тогда о какой логике идёт речь? Или, всё-таки, что-то устраняет?

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

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

Сам процедурный тип и является в аналогии с ООП абстрактным методом, что хорошо видно в примере заглавного сообщения. Это никак не связано с NIL в процедурной переменной, который в такой аналогии является NIL в переменной-указателе на запись с методом.

Я имел в виду эмуляцию абстрактной процедуры в КП средствами Оберона. По поводу NIL - в моем случае его надо присвоить только процедурному типу, позволяя пользоваться другими полями записи, а в вашем - его необходимо присвоить всей записи.
Во всяком случае, я так понял ваше сообщение.

чистая оптимизация: не нужно создавать в куче новый объект, и одним индиректом меньше. ну, и удобство портирования кода в стиле «что вижу — то и пою» с языков, где это есть.

Поэтому я и ранее спрашивал - вас беспокоят накладные расходы или дело в принципиальных архитектурных особенностях? Создаётся впечатление, что последнее, и тогда это более интересно, но конкретики не предоставляется.

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

Это просто не нужно делать в таком виде в большинстве случаев.

"Вся запись", может состоять из объекта с одним методом, лежащего в другой записи. И даже фактически это может быть всё тот же адрес кода при соответствующем воплощении.

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

но на самом деле: на практике я почти не помню случаев, когда мне не надо было бы вместе с указателем на процедуру передавать ещё и какой-то контекст. то есть, в большинстве случаев я просто эмулирую объект с полями и методом, получается.

в принципе, процедурный тип получается такой же избыточностью, как и FOR, да. но поскольку у нас язык не только для «верхнего уровня», но ещё и так называемого «системного программирования», то процедурный тип в нём таки нужен для мелкооптимизаций совсем-совсем внизу. однако, возможно, его стоит разрешить только при импорте SYSTEM, например.

p.s.: даёшь делегаты!