> -- Rifat писал(а):
> Читаю книгу "Object-oriented programming in Oberon-2" и там есть описание простой оконной системы, которая называется Oberon0 (не путать с простым компилятором Oberon-0, из книги "Compiler construction"). Так вот Frame-ы и Viewer-ы описываются следующим образом...А что, если ......Какие у данного метода могут быть недостатки?Может быть данный метод уже где-то был реализован?
Рифат, Ваш вопрос - несколько шире, чем конкретная реализация View.

В данном случае (как и во многих других), Вирт сделал методологическую и архитектурную ошибку, внеся знания о возможных отношениях, в которых может быть задействована и/или участвовать данная сущность в саму сущность.
Если таких отношений может быть всего одно ( как в случае со списком views ), - это кажется несущественным.
Но, исходя из общих подходов, лучше сделать общий класс List, оперирующий с элементами ЛЮБЫХссылочных/указательныхтипов.

Тогда бы и вопроса о том, каков способ создания и место нахождения экземпляра не имел бы значения.

Как только мы приходим к такому решению на уровне системы, моментально возникает задача (де)инициализации.
Эта задача также переходит на уровень общесистемной.
То есть, экземпляр может быть в куче или где-то статически. Инициализировать (экземпляр) нужно в любом случае.
Возникает инициализирующая часть. OurType_Init( OurTypePtr self, ...args...).
И - для размещения в куче, что-то "фабричное" - OurType OurType_Create( ...args... ), которое может вызывать ( может и - нет ) ***_Init.
Соответственно, можно организовать ***_DeInit & ****_Free (последний - для тэггированных типов).

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