Ответ на »сообщение 2720« (Антон Григорьев)
___________________________

Обязательная проверка границ массива снижает быстродействие программы в среднем на 5%.

Неправда. В мало-мальски реалистичных случаях это скорее 1-2%, когда вообще удается измерить.

Ответ на »сообщение 2742« (Антон Григорьев)
___________________________

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

По-грамотному делается так:
Экспортируется ABSTRACT-тип.
Фабрика выдает скрытую реализацию.
Клиент расширяет ABSTRACT-тип, а объект скрытой реализации использует как компоненту -- это и есть "композиция" (частный случай, конечно).

Ответ на »сообщение 2742« (Антон Григорьев)
___________________________
можно ли в Обероне создать такой тип, что его экземпляры можно будет создавать только через фабрику, но при этом другие модули не потеряют возможности создавать расширения этого типа?

Это невозможно по определению. Ведь единственный способ запретить создавать обьект в обход функции-фабрики - это сделать его private, то есть спрятать от других модулей. А это значит что снаружи вы его не увидите, и как следствие никаких классов от него наследовать не сможете.
Приходится выбирать - либо конструктор, либо наследование :))

Ответ на »сообщение 2734« (AVC)
___________________________

При этом, в отличие от конструктора, она остается обыкновенной подпрограммой, способной к тому же выполнять обязанности "виртуального конструктора" (на что конструктор не способен).
Т.е. она одновременно проще и гибче конструктора.

Почему ж не способен? От реализации зависит. В Delphi, например, конструкторы могут быть виртуальными, и на этой особенности вся библиотека VCL построена.

Кстати, хотелось бы увидеть пример, как фабрика может заменить виртуальный конструктор вот в таком случае:

Есть модуль A. В нём объявлен тип A.B. И в этом же модуле есть некоторая процедура A.X, которая для своих внутренних нужд может создать экземпляр любого типа, являющегося расширением A.B. Какого именно типа - это передаётся процедуре A.X извне через её параметры. Модули, в которых определяются расширения типа A.B, а также осуществляются вызовы A.X, на момент компиляции модуля A ещё не существуют. В Delphi через виртуальные конструкторы и указатели на классы это делается элементарно. А в Обероне?

И прошу не оставлять без внимания такой вопрос (его уже озвучил Jack of Shadows): можно ли в Обероне создать такой тип, что его экземпляры можно будет создавать только через фабрику, но при этом другие модули не потеряют возможности создавать расширения этого типа?

Ответ на »сообщение 2736« (Jack Of Shadows)
___________________________
О том что такое такой вот набор design patterns "грамотного проектирования" в ОО языках, разговор на ветке ФП уже был.
Джек, если не притомит - бросьте конкретный адресок этого эпизода на эту тему...
Programming in Lisp is like bike riding! Having results just after thoughts! :)

Ответ на »сообщение 2732« (Сергей Перовский)
___________________________
>>> в Дельфи другого пути просто нет.

type PR= ^record ...

Записи Оберона соответстсвуют скорее записям, а не объектам Дельфи.

Ответ на »сообщение 2738« (AVC)
___________________________
Хм... а как пишется конструктор?
Если в вашем распоряжении имеется конструктор. то вам не надо:
1. Прятать обьект, закрывая его интерфейсом.
2. Спрятав обьект терять возможность его наследования. С конструктором вы можете иметь и то и другое - и наследование и интерфейсы.
3. Напоминать себе писать функции фабрики, потому что в большинстве случаев они не нужны.

Если это "тот самый" механизм, почему для него в языках с конструкторами существует целый ряд паттернов проектирования?
Если вы о фабриках то они не для конструирования обьектов. Они для параметризации, то есть унифицированного механизма создания РАЗНЫХ обьектов.
Для создания одного и того же обькта (а это в подавляющем большинстве случаев) фабрика не нужна, конструктора вполне достаточно.

И кстати это тоже показывает ограниченность ОО как инструмента.

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


Да, но задача сохранения целостности данных одна на всех и не зависит от набора полей и их типов :))
Следуя вашему аргументу можно заявить что раз в таблицах базы данных разное количество и тип полей то и транзакционность мол в каждом случае должна обеспечиваться силами самой таблицы :))

Ответ на »сообщение 2736« (Jack Of Shadows)
___________________________

Но все это надо делать ручками.

Хм... а как пишется конструктор?

ТО есть каждый раз создавать тот самый механизм от которого отказались :))

Если это "тот самый" механизм, почему для него в языках с конструкторами существует целый ряд паттернов проектирования?


AVC: Т.е. она одновременно проще и гибче конструктора.
Ошибаетесь. Если бы это было так то эту вот общую задачу корректной инициализации обьектов можно было бы как нибудь выделить в виде библиотечной функции.

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

Ответ на »сообщение 2735« (Сергей Перовский)
___________________________

Ответ на »сообщение 2734« (AVC)
___________________________
>>>Фабричная процедура позволяет делать ровно то же самое, что и конструктор
Мы не про то. Конечно позволяет.
Но она позволяет НЕ делать.

Илья Ермаков привел схематичный пример (»сообщение 2729«) с поправкой: (»сообщение 2730«), опровергающий это Ваше утверждение.


>>>класс = тип + модуль
Это я не понимаю. Термин модуль используется в значениях единицы текста, единицы трансляции, единицы загрузки. Ни под один из этих смыслов класс не попадает. Специальный тип данных, не более.


Как насчет единицы инкапсуляции (разделение интерфейса и реализации)?
Вообще, формулу класс = тип + модуль не я придумал (а Б.Мейер).