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