OberonCore

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

Так чего не хватает в FINALIZE? Закроем файлы, то да сё. А еще что?

Вопрос в том, когда мы это сделаем.
FINALIZE вызывается сборщиком мусора, а тот может сработать в неопределенное время.
Краткое сопоставление финализатора и деструктора:
http://ru.wikipedia.org/wiki/Финализатор

Так можно его заставить: Services.Collect.

А если микросекунды важны, то всё равно надо особый механизм сочинять.

В том и вопрос: нужен ли такой механизм?

Я имел в виду, что нужно просто делать уже имеющимися средствами в зависимости от задачи. Какой может быть общий механизм, если речь о микросекундах?

Ещё в какой последовательности. ББ вызывает финализаторы в неочевидном порядке

Это решается: если есть какой-то нужный порядок, то соотв. объекты должны быть как-то повязаны друг с другом и координироваться между собой, чтобы обеспечить нужный порядок вызовов каких-то реальных процедур финализации. Тогда FINALIZE -- некий фасад, приемник сигнала о начале сбора мусора. А принимает, по сути, -- вся координированная общность объектов.

Хотел спросить пишущих на до-диезе (если такие есть; кажется, Сергей Губанов одно время писал на нем): что это за паттерн dispose?
Пользуетесь ли вы им?
Применим ли он в каком-нибудь виде к BlackBox?

Существует известный паттерн RAII, родившийся в языке Си++.
http://ru.wikipedia.org/wiki/Получение_ресурса_есть_инициализация
В языках с GC использованию этого паттерна мешает неопределенность времени вызова финализатора (т.е. ресурсы освобождаются не сразу).
Но есть какие-то подпорки вроде паттерна dispose в C#.
Впрочем, я согласен, что цель не в изменении языка, а в решении проблемы. Если есть способ удобно ее решить, не трогая языка, имеет смысл так и поступить.

Собственно, весь паттерн-то состоит в наследовании от единого интерфейса с единым методом.

А так в ББ для таких случаев и применяется спец. метод Close (если не вызвали его явно, тогда уже добивает финализатор). Files.File. SqlDB. И т.п.

Насколько я понял, это был пример проекта, где использование такого-то инструмента не потребовалось. Чтобы не возникало вопросов "применимо ли это к моему случаю". Просто, описание, возможно, чуть затянулось...

Ну пока в обероне нет исключений, то можно как-то жить и без деструкторов. При наличии исключений - да, совсем грустно. Можно попробовать пообсуждать возможные решения Например:
1) Связываем с записью процедуру-деструктор. Для определенности назовем такую запись по аналогии с C# - disposable.
2) Деструктор вызывается при выходе disposable-записи из области видимости.
3) disposable-запись можно передавать "вниз" (как параметр процедуры) и "вверх" как результат функции.
4) Если disposable-запись была возвращена как результат, то деструктор для нее в текущей процедуре не вызывается.
5) В вызывающей процедуре disposable-запись "принимается" "инициализацией по месту" локальной переменной.
6) disposable-запись, переданную как аргумент, нельзя вернуть (можно попробовать разрулить это чисто синтаксически, сделав несовместимыми тип аргумента и тип возвращаемого значения).
7) disposable-запись может быть только локальной переменной или полем агрегирующей disposable-записи.

Например так:
Тип аргумента будет "VAR <тип>" (ссылка), тип возвращаемого значения - просто "<тип>" (значение). Значение может быть приведено к ссылке, но не наоборот.

Вкратце -- большой нужды в Dispose не возникло, использовался на всякий случай в связи с неродными для managed-среды ресурсами...

Если есть выбор -- иметь Dispose или не иметь, то лучше иметь (имхо).
Но это противоречит духу оберонов, где ответ -- раз не является жизненно важным, то не иметь...

Это не паттерн. Это синтаксический сахар языка C#. Позволяет вместо текста:
писать более кратко:Для этого нужно чтобы тип X реализовывал интерфейс System.IDisposable

К этой же самой разновидности синтаксического сахара относится и lock:
разворачивается компилятором в

Какое отношение имеет наличие Dispose (введение принудительного освобождения для конкретного вида ресурсов) к принципу минимализма?
Это всё равно, что сказать: "раз не является жизненно важным, то луче не синего цвета".
Касательно того, вводить или не вводить - всё сильно зависит от конкретного случая. Например, допустим ли риск, что один компонент, закрыв разделяемый ресурс, нарушит этим работу остальных.

Я уже сказал, что явное освобождение ресурсов (метод Close) используется в ряде модулей среды).

"Дух оберонов" заключается в признании того, что программеры склонны делать ошибки, и нужно уже на уровне проектирования языка уменьшить эту вероятность.
Минимализм языка -- следствие этого.

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

Так что опять Geniepro продемонстрировал свою фирменную поверхностность -- и неудержимую страсть к клеветам.

Ну в этом случае в обероны таки следует добавить систему интерфейсов (так как ручное манипулирование метаинформацией чревато ошибками), добавить интерфейс IDisposable и синтаксическую конструкцию using, которая и впрямь очень удобна и повышает безопасность.
Хорошо бы ещё добавить for each, ибо куда без него...
В свою очередь info21 продемонстрировал свою фирменную и неудержимую страсть к переходам на личности. Всё правильно...

Спасибо!
Я примерно так и думал, но не знал наверняка.