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

>>>Не понял, пример в студию.

Цитата (и пример с интернализацией/экстернализацией) из раздела 3 краткого руководства по ББ (входит в его поставку):
Implement-only export is a prime example of a feature motivated by typical framework design patterns. A record type's methods may be exported as implement-only, by using a dash instead of an asterisk. An implement-only method can only be called inside the defining module. But it can be implemented outside the defining module, in an implementation component of the framework. For example, the BlackBox Component Framework's store mechanism uses this feature to protect a store's Internalize and Externalize methods from being called out of their correct context. Basically, the framework (in this case the Stores module) uses the implement-only methods in all possible legal ways (i.e., implements all legal kinds of use-cases), and only exports them for implementation purposes.

Ответ на »сообщение 3554« (AVC)
___________________________
Не понял, пример в студию.

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

>>>Ну а вот теперь и расскажите нам на примере простенького доступа к одному единственному полю SSN, как же вам тут модульность оберона поможет ?

Думается, здесь неплохо сработают т.н. implement-only методы КП.

Ответ на »сообщение 3540« (Axcel)
___________________________
>>>Есть противоречие между наследованием реализации в ООП и необходимостью отчуждения программного продукта с последующим его развитием.
Пожалуй правильно. Вот только в сложных задачах невозможно отчуждение программного продукта "в пользу" безграмотного пользователя/программиста.
Я уже говорил о том, что считаю ООП инструментом системного аналитика. Не больше, но и не меньше.
Я отнюдь не сторонник того, чтобы все программы делались на основе ОО подхода с наследованием по реализации. Но своя ниша у такого подхода есть.

Ответ на »сообщение 3549« (Илья Ермаков)
___________________________
Приведу пример очень маленькой задачи, которая плохо решается средствами ООП, но хорошо аспектами.
Часто надо бывает показыват данные полностьЮ частично или не показывать вообще в зависимости от уровня доступа пользователя. Например поле Social Securty Number.
Полный доступ - показывать 123-45-7892
Частичный доступ, показывать только последние 4 цифры: XXX-XX-7892
Нет доступа не показывать вообще: XXX-XX-XXX

Если делать средствами ООП, то можно конечно прямо в обьект, в котором содержится это поле, забить логику.
Но тогда либо придется передавать обьекту права доступа пользователя, либо передавать ему id пользователя и пусть обьект сам выясняет его права, либо пусть читает права пользователя с глобальной переменной.
В любом случае это получается каша. Данные не должны заботиться о такой фигне как кто их смотрит.

Второй вариант - проверять на местах, то есть везде ставить эти if-ы и надеяться что в будущем новый программист, не забудет это сделать.
Тоже хреновый способ.

А с аспектами весьма удобно, и главное МОДУЛЬНО. То есть код отвечающий за проверку доступа не перемешивается ни с обьектами хранящики данные, ни с кодом, выдающим эти данные пользователю.
Просто при каждом обращении к полю SSN, за сценой вызывается функция проверки доступа, которая перехватывает чтение поля, и заменяет данные в соответствии с правами доступа.
Таки образом обьекты, хранящие данные на забиваются всякой не относящейся к ним машинерией, Так же как и код вывлжа информации. Да и безопасность на уровне. Будущий новичок программист может совершенно спокойно бросать это поле на экран, не боясь, что он что то кому то не то покажет.

Это очень маленький пример. В реальности, правила доступа невероятно сложны и зависят от множетсва параметров. Да к тому же и переплетены так что никак их отдельно в ООП системе не опишешь.

Ну а вот теперь и расскажите нам на примере простенького доступа к одному единственному полю SSN, как же вам тут модульность оберона поможет ?

>>> никто не ставит на одну машину и дизель, и карбюраторный двигатель; и колеса,
>>> и гусеницы, и крылья, и понтоны.

Абрамс, например, имеет и турбину и дизель и гидро- и электропривод.
Гусеницы без колес - так это ж разве шагающий экскаватор :)
Шведский танк есть - трансформируется в понтон - забавное решение.
Сканер-принтер-копиры и смартфоны вытесняют специализированные устройства.
Развитая техника довольно универсальна. Так что неудачная аналогия.

Другое дело модульность. За счёт применения модульности время обслуживания
движка Абрамса было сокращено с 4 часов до 30 минут!

Ответ на »сообщение 3549« (Илья Ермаков)
___________________________
В свете поднятой роблемы, как она будет решаться по другому нежели в mainstream ООП языках ?

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

Ответ на »сообщение 3542« (slava)
В третьих, может есть альтернативное решение? Может в Оберон-системах, это решается по-другому?
А что уже есть какое то отдельное Оберон-программирование, которое в принципе отличается от ООП ?

Эх, Джек, как Вы невнимательны к чему-либо, что обсуждается за пределами ФП :-)
Сотни сообщений на тему кластерно-модульного проектирования как альтернативы ООП были, увы, напрасны :-)