OberonCore

С ресурсами низкого уровня напрямую не работают. Делают культурный высокоуровневый интерфейс. Тогда у Вас будет объект Query, а не хэндл какой-нибудь. И объект будет собран сборщиком. Может быть, не сразу. Но и "что-то меня выбросило" происходить должно не каждый месяц в году.

Да. Но взаимодействие с внешней средой должно очень хорошо локализовываться и заворачиваться в хорошие высокоуровневые абстракции.
А в ряде мест внутри их реализации можно использовать библиотечные средства.
Например, вот эту реализацию try-catch:
viewtopic.php?f=2&t=294

Идея деструкторов как раз и заключается в том, чтобы не делать их работу вручную...

Наоборот. Потому что сбой очень часто возникает из-за исчерпания ресурсов.

Александр, наверное, имел в виду следующее. FINALIZE- не доступны по вызову напрямую, их вызывает только сборщик мусора (автоматически). Но если мы используем для освобождения ресурсов дополнительный (другой) метод, то его можно будет вызвать и напрямую. (Кстати, иногда, хотя редко, в Си++ вызывают деструктор напрямую.)
Думаю, ничего другого здесь не имелось в виду.

Мне кажется, что программисты условно делятся на две группы На тех, кто хочет видеть кишки во всех подробностях, и на тех, кто хочет эти кишки спрятать как можно глубже и не мешать им работать. Первые выбирают C или оберон, вторые - C++ или что-нибудь функциональное. И те и другие смотрят на одну и ту же вещь с разным знаком. Например, первые считают "вызов тучи конструкторов" злом, потому что они теряют контроль над ситуацией. Вторые считают "вызов тучи конструкторов" благом, потому что ситуация полностью под контролем (компилятор не забудет сделать все что надо). Одни хотят явно писать "Close", другие отдают эту задачу компилятору. Ну и т.д. И переубедить кого-то из этих лагерей нет никакой возможности, это просто особенность психологии.

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

Именно это я и имел в виду, спасибо : )

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

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

Стоит вспомнить Esmertec c их JBed, а до этого OS Portos, на которой можно было исполнять модули на Компонентном Паскале. Интересно, как они решали эту проблему?

Память Вам не изменяет.
У RESCUE там еще есть аргумент-исключение. Примерно так:

Возможно, пора подвести какой-то итог, а то тема, кажется, заглохла.
Меня это обсуждение подвигло усомниться в необходимости объектных деструкторов для Оберона. (Вообще-то, изначально, опираясь на опыт Си++, я в ней мало сомневался.)
Какие могут быть причины ввести в Оберон/КП деструкторы?
1. Освобождение памяти.
В основном деструкторы Си++ занимаются освобождением памяти. Рантайм Оберона полностью берёт эту работу на себя. Это мне было ясно и до обсуждения.
2. Освобождение внешних ресурсов (файлов, устройств и т.д.; потоки я здесь не рассматриваю).
В КП есть финализаторы. Рано или поздно они сработают (при сборке мусора), и внешние ресурсы будут возвращены. Но здесь остается общая для финализаторов проблема - непредсказуемость времени их вызова. Поэтому мы переходим к следующему пункту.
3. К какому событию привязать освобождение внешнего устройства.
Сначала казалось очевидным, что к уничтожению объекта, управляющего внешним устройством.
Но потом я стал в этом сомневаться. Например, в прежние ("дообъектные") времена считалось хорошим тоном освобождать ресурсы в той же процедуре, в какой их захватывали. Думаю, то же можно распространить и на метод. Учитывая, что внешние устройства (по большей части файлы) используются значительно реже, чем динамическая память, можно применить этот "старый" подход. (Исключения настолько редки, что, IMHO, такими объектами без труда можно управлять и явно.) Но тогда возникает новая опасность: в результате выброса исключения мы можем не выполнить действия по освобождению ресурса в конце процедуры.
Это приводит к следующему пункту.
4. Процедурные секции CLOSE (по аналогии с модулем) и их привязка к обработке исключения.
Можно ввести секции в язык процедурные секции CLOSE (аналог finally) и поручить обработчику трапов их вызвать (в порядке LIFO, разумеется). Уверен, что это не является проблемой. Таким образом, мы гарантируем своевременное освобождение внешнего ресурса даже в случае исключения.
5. Каких проблем мы избегаем, не вводя конструкторы/деструкторы.
Конструкторы и деструкторы обычно работают не так, как другие методы. Они предполагают вызовы для всех классов в иерархии наследования и агрегации. Учитывая,

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

то, отказываясь вводить в язык конструкторы/деструкторы, мы избегаем излишних хлопот и большой головной боли.
Поэтому я предлагаю ограничиться введением процедурной секции CLOSE (хотя еще надеюсь на некий аналог секции EXCEPT (XDS) или RESCUE (GPCP)).
Это, конечно, IMHO. Можно критиковать.

Строго говоря, есть альтернативы введению процедурной секции CLOSE в КП.
1. Гарантировать вызов сборщика мусора после каждого исключения.
В таком случае, как и сейчас, ответственность возлагается на FINALIZE-.
2. Ввести модуль, регистрирующий объекты, наследующие (скажем) типу Disposable.
В случае исключения, для зарегистрированных объектов гарантировать вызов метода Dispose, после чего отменить регистрацию (чтобы впоследствии они могли быть собраны сборщиком мусора). Тогда не обязательно вызывать сборщик мусора, можно ограничиться вызовом DisposeAll. Регистрацию можно отменить и явным вызовом Dispose.

Но у секции CLOSE есть дополнительное преимущество. Благодаря встроенности в компилятор, она позволяет упростить написание выхода из процедуры. Достаточно вызвать RETURN, а секцию CLOSE тогда вызовет сам компилятор.

Согласен с Вами. Конструкторы и деструкторы излишни в Обероне. А вот разделы EXCEPT и CLOSE пригодились бы.

Спасибо за поддержку.
Мне эта мысль (об излишнести конструкторов/деструкторов в Обероне) далась с трудом из-за привычек программирования на Си++.

В O7 (Oberon-07) нет возможности выскочить с середины функции. Если рассматривать применимость предложенной секции CLOSE к О7, то приходим к выводу о ее (почти) полной бесполезности. Далее мне все равно не понятно, а кто будет делать CLOSE секции CLOSE ? И кто будет ловить exceptions в секции CLOSE ?
Ах да! В секции CLOSE будет очень простой код, чистый от багов и исключительных ситуаций! Одни из самых тяжелых багов в Ц++, это exception thrown в catch-блоке.

ИМХО, все это не является достаточно чистыми концепциями, что бы их вводить в какой либо из Оберонов.

Модули загружаются и выгружаются в непредсказуемое время (либо автоматически, либо по требованию пользователя), поэтому использование CLOSE в модулях довольно оправданно (если б его не было, его бы эмулировали некими процедурами). Чего не скажешь о процедурах, в которых явно известно, где ее начало и где конец (особенно в O7).

Единственная "проблема" -- это exceptions. Мне кажется, нужны совершенно другие подходы. Реализация exceptions в Ц++, ИМХО, полностю себя дескредетировала, и не стОит все это тащить в Обероны.

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

В Обероне-07 вообще ничего нет.
Этот маленький язык - большая ошибка.

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



В чем именно дескредетировала? Это не самая страшная часть плюсов

По поводу except. Честно говоря, не уверен, правильно-ли это, но мне всегда хотелось связать использование ASSERT с обработкой исключений. Так сказать скрестить "ежа" с "ужом". Т.е. во время разработки/отладки программа при нарушении ASSERT ведет себя как "еж" ( trap), а во время эксплуатации как "уж", т.е. какая-то мягкая обработка в секции EXCEPT или как-то еще (что-нибудь вроде ON_ASSERT).

IMHO, так и должно получиться.
Например, во время отладки ASSERT перехватывается отладчиком, а во время эксплуатации генерирует исключение, которое может быть обработано в секции EXCEPT.