Оберон-клуб «ВЄДАsoft»

Ну так а зачем абстрактные записи в КП? Они для этого и введены. Чтобы решить проблему хрупких базовых классов.

Comdiv, Вы сначала утверждаете, что "ООП модель а Компонетном Паскале на данным момент считается не очень удачной". Говорите за себя: "Я считаю модель...", уже будет корректнее. А то у Вас получается, что все резко сочли модель ООП в КП не слишком удачной. Хотя про КП вообще мало кто слышал.

Далее ещё интереснее: "в мире прошла ООП-эйфория и появилась тенденция более ограниченного ООП (Go, Rust)". Читаю так: "[Минималистичная с точки зрения КОП] модель ООП в КП видится Comdiv'у не очень удачной, потому что в Go и Rust появилась тенденция более ограниченного ООП" [которое, правда, что в Go, что в Rust'е несоизмеримо жирнее КП'шного]. Ну прям логика абсурда.

1. Абстрактные записи не решают эту проблему.
2. ООП модель КП не уникальна.
3. ООП модель в Go и Rust не более жирная, особенно в Rust. И речь не ожирности, а о типе отношений между базой и расширениями.

1. Абстрактные записи подходят вплотную к решению этой проблемы.
2. ООП модель КП уникальна тем, что она реализует минималистичный КОП.
3. ООП модель в Go и Rust конечно же более жирная. Речь о том, что ООП в КП попроще, чем в них.

А какие конкретно недостатки в ООП-модели КП?

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

Не говоря уже о менее классических, но интересных подходах - например как в Go.

Правильное множественное наследование интерфейсов сделано в функциональном языке -- хаскелле. Это классы типов.
Сишарп тихонько идёт в этом направлении -- все эти его extension method'ы -- это начальный шаг на пути к классам типов...

Избыточность. В отношении действий желательна связь Интерфейс -> Воплощение в противовес возможности богатых иерархий с сильной связанностью.

ABSTRACT, EMPTY, EXTENSIBLE и LIMITED как раз сделаны, чтобы разработчик каркаса смог управлять наследованием и избежать неправильного использования, проблемы хрупких базовых классов и т.п. Это "флаги" компонентного ориентированного программирования. Суть заключается в том, чтобы не дать возможность слепить продукт из "того, что было". Если нужно кардинально что-то переделать, то идет замена компонента (подсистемы) целиком, а не городьба заплаток, уточнений и переопределений.

Как человек, который уже 10 лет использует ООП в Компонентном Паскале на полную катушку, скажу, что модель ООП в нем очень удачная.
Отсутствие множественного наследования скорее возможно записать в плюс, так как сегодня такие задачи рекомендуется решать композицией.

Я понимаю, что атрибуты позволяют гибко управлять, но это не нужно. Достаточно абстрактной записи со всеми абстрактными методами, которая расширяется до конкретной записи со всеми уже определёнными методами. Тогда не нужно ни ABSTRACT, ни EMPTY, ни EXTENSIBLE, ни LIMITED и NEW.
В Java тоже есть большая система сдержек, тем не менее мои коллеги наворачивают иерархии, которые и проектировать сложно, и поддерживать. КП тоже позволяет наворачивать, а самодисциплины можно везде придерживаться.

Абстрактная запись требует реализацию в обязательном порядке. А пустая только по необходимости. Например, вы можете сделать отображение Views.View, и обязательно только объяснить каркасу, что там рисовать Restore, но обрабатывать сообщения HandlePropMsg или пользовательский ввод HandleCtrlMsg в этом отображении — это уже опции, которые пользователь каркаса может и не уточнять в конкретной реализации, если не требуется. Для этого нужен EMPTY, это абстрактная запись, реализовывать которую не обязательно при создании наследника. Так что EMPTY очень даже полезен при проектировании таких элементов каркаса.