OberonCore

Хотелось бы составить перечень (реестр ) паттернов и приёмов программирования, специфичных для Оберона.
Речь идёт именно о приёмах, специфичных для языка, а не об общих правилах "хорошего тона" (вроде структурного программирования).
Некоторые из них достаточно очевидны. Например, использование программной шины или фабричных функций вместо конструкторов.
Некоторые менее очевидны (или являются уже производными от более очевидных). Например, кэширование памяти для повышения эффективности программ. (Например, http://forum.oberoncore.ru/viewtopic.php?p=20109#p20109.)
Интересует именно повседневная практика, "будни" языка, позволяющие подвергнуть язык обоснованной критике и исправить недостатки.

Паттерн Carrier-Rider возник в механизме доступа к файлам в Системе Оберон.

В общем виде сформулирован Шиперским в 1992 как (по-моему, сравнительно тривиальное) обобщение.

Источник: Oberon – The Overlooked Jewel, Michael Franz
http://www.ics.uci.edu/~franz/Site/pubs-pdf/BC03.pdf

Спасибо.
Начало положено.

Хорошо бы тут собрать, а потом в Wiki перенесть....

Согласен.
В принципе, хотелось бы даже, чтобы набралось материала на маленькую электронную книжку "Практическое программирование на Обероне/КП", которую потом выложить на OberonCore.ru. (Более детальный вариант Вашей статьи, посвященной Оберон-технологии.)
Маэстро Вирт справедливо славится краткостью и ясностью изложения, но при таком подходе, кажется, недостаточно освещаются некоторые вопросы, возникающие у программиста, который недавно начал использовать Оберон всерьёз (не только для учебных задач).
Некоторые поклонники Оберона (вроде меня ) вынуждены программировать на нём "набегами", не проникаясь всеми его возможностями, в отличие от тех, кто программирует в ОС Оберон или в ББ.

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

Всегда нужна "теорема существования".
А здесь -- взял ББ, поизучал -- вот и все паттерны.
-----------------------
Выделю еще "композицию" вместо наследования.

В принципе я тоже так знакомился с ББ, только все таки очень помогла в изучении статья
про Оберон технологии( и до сих пор мне хочется иметь намного расширенный вариант этой статьи). Сейчас я активно просматриваю документацию ББ статьи преосвященные ББ так что в скором времени пополним эту ветвь. А пока немного про хорошо известную модель MVC , хотя она и появилась в Смолтолке, но за счет свойств Оберонов она приобрела новые возможности.
1.В Смолтолке во главу угла поставили объекты и передачу сообщений между ними, объекты объединялись в классы (кстати в литературе про Смолтолк часто говорится что классы это модули,
но мы знаем к чему это привело такое не понимание , хотя в инете много инфы про применении MVC в разработке программ на Яве или С# и модификаций данного паттерна, но они даже приблизительно по мощности не достигают возможностей оберонов.
З.ы хотя и много уже говорилось про MVC, но всетаки есть задумка сравнить применение данного паттерна в Смолтолке, Кп и Яве.

Спасибо.
Сначала я подумал, что здесь нет ничего специфического. Ведь предпочтение композиции наследованию (вместе с программированием в соответствии с интерфейсами) - один из основных принципов "банды четырёх".
Но потом вспомнил, что обероны - языки модульно-компонентного программирования, и здесь ограничение (межмодульного) наследования имеет особое значение.

А какие именно возможности?
Да, это было бы очень интересно. Особенно в сравнении со Смолтоком.

H. Mössenböck. Twin - A Design Pattern for Modeling Multiple Inheritance.
J. Temp. A systematic approach to multiple inheritance implementation.

Второй файл почему-то не открывается (после загрузки - на моем столе). Пишет, что файл не найден.

Это из-за немецких букв o с умляутами (точками вверху). Переименуйте файл.

Спасибо!

А ниче текстики, спасибо!

Я тоже интересуюсь этой темой. Мне бы очень хотелось увидеть какие-то примеры проектирования программ на Обероне-2. Например, создание простенькой игры. Причем этот процесс должен объясняться по шагам. Нет, не процесс программирования (написание модулей), а именно проектирования (взаимодействие модулей). Тут все комментарии свелись к тому, что "это так просто в Обероне, что и смысла рассказывать нет". К сожалению, есть такой парадокс: когда человек что-то знает хорошо, он не может это хорошо объяснить. Это называется "Проклятие знания"

О многом говорит хотя бы тот факт, что вот этот пост за 8 лет так и не удостоился ответа - viewtopic.php?f=5&t=254
Знаете, почему люди пишут на C# и Python? Потому что на любой вопрос легко гуглится ответ, а то и сниппет. Я так на VB.NET однажды прогу написал.

Вот мне, например, надо написать программу на Обероне-2. Конечно, можно постепенно осваивать его, реализуя все более сложные программы. Начиная с какой-нибудь ерунды типа восьми ферзей. Проблема в том, что так я научусь только записывать алгоритмы на этом языке, а это дело десятое. Алгоритмизировать я и так умею. Я говнокодер с 30-летним стажем. Но вот модульное программирование для меня в диковинку. Каких-то паттернов и best practices я не нашел (глупый гугль думает, что я хочу изучить ООП), за исключением тех ссылок, что в этой теме (большое спасибо, завтра почитаю, сейчас уже глаза и попа болят), а также принципа CQRS, который применим к любому ЯП, а значит, и к Оберону.

http://oberoncore.ru/library/kuzmiczkij ... e_blackbox (...
27 апреля 2009г.
Библиотека, Кузьмицкий И.А., ББ, Образование )

http://oberoncore.ru/library/ermakov_gr ... _pokazanij
http://oberoncore.ru/blackbox/tutorial

P.S. http://oberoncore.ru/wiki/lang/component_pascal

Паттерны говорите.

Берём книгу, фундаментальные алгоритмы(Для болей близости к оберону, есть редакция для delphi).

Всё остальное, это всяко разные апи, движки, фреймворки.

Алгоритмы - это алгоритмы.

А речь о приёмах организации программ на среднем уровне (уровень декомпозиции и организации взаимодействия частей; решение всяцских проблем этого уровня - надёжность, сопряжение компонентов разных разработчиков, безболезненная длительная эволюция...). Этот уровень уже очень языковозависим. Наиболее языковозависим (в отличие от алгоритмов, которые можно перевести 1-в-1 с языка на язык, и в отличие от крупного уровня, где можно сопрягаться над базами данных либо протоколами обмена сообщений).