Структуры не могут эмулировать модули. В С++ структуры (они же классы) пытаются эмулировать модули - получается погано.

Типов модулей тоже не нужно. Мне бы (если бы текущий проект писался не на С++ а не Обероне) было бы нужно (и достаточно) чтобы был мехинизм генерации модуля по некому заданному шаблону + имени. Частичной генерации. Т.е. что-то генерируется само (и это для пишущего модуль - read only информация), а что-то программист может дописать сам.

Тут есть два пути - либо синтаксическая конструкция в языке, либо текстовый редактор умеющий это дело генерировать (правда при этом не будет ограничения на ro, ну да ладно) + сворачивать этот, зависящий только от имени модуля и имени(типа) шаблона, код в некое компактное представление на экране.

Ответ на »сообщение 2274« (RBV)
___________________________

А вот принципиальную сторону дела можно изложить и здесь.

Да, с этим, наверное стоит туда...

Ответ на »сообщение 2254« (info21)
___________________________

Ответ на »сообщение 2250« (Alexey Veselovsky)
___________________________

на Обероне либо не появились бы вообще, либо решаются достаточно просто. Да, арифметика указателей и сборщик мусора тут не при чем.

Любопытно, что именно там было. Если строгая типизация, то ясно.

Чуть попозже подробно отвечу что и к чему. Но сразу скажу - это и не строгая типизация тоже.

PS. Быть мне стоит написать это не сюда а в форум по BB? Все же это частности языковые, а не какие-то там абстрактные технологии... Да и у форума того есть преимущества - там есть "типизация" сообщений (по веткам обсуждений) а тут нет - все в одну кучу.

Ответ на »сообщение 2267« (Снегурочка)

...микромодуль - это RECORD-структура...

Очередная попытка сделать чего-то от балды: сначала предлагается решение, а потом ищется задача, которую оно решает. Надо от задачь отталкиваться.

То же самое касается обсуждения по объединению Оберона с Хаскелем - ну на фига козе баян???

Ответ на »сообщение 2266« (Владимир Лось)

То, что вы в данном случае определяете как "состояние"...

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

Ответ на »сообщение 2269« (Снегурочка)
___________________________

Памятуя, что Оберон можно рассматривать как ассемблер ООП (я бы назвала - ассемблер расширяемых типов), имеет смысл поизучать возможности различных композиций применительно к реальной потребности в generic-вещах.

Подобные вещи возможны и в классическом Обероне, и в Обероне-2, и в КП. Если брать за основу ООП, то из этой тройки язык КП ближе всех стоит к мэйнстрим-трактовке ООП (Java), а классический Оберон - к хоаровской трактовке ООП на основе record class. Если исходить из мэйнстрим-трактовки (class-centered подход с пожизненной фиксацией методов для всех объектов класса), то procedure type ("процедурная коммутация") и instance-centered подход классического Оберона (объекты одного класса с разными "персональными" методами) выглядят рудиментами и атавизмами. Но кто сказал, что мэйнстрим-трактовка идеальна и подходит для всего на свете?

"Аристократии" классов Вирт предпочитал "рабоче-крестьянскую" среду модулей. "Рудименты" и "атавизмы" из КП не убраны, значит, можно попробовать и там поискать выигрыш, который дает "ассемблер расширяемых типов". Ну а работа с метаинформацией в КП вроде бы вполне приличная.

Ответ на »сообщение 2267« (Снегурочка)
___________________________

Раз микромодуль - это RECORD-структура, ее можно экспортировать-импортировать и расширять ("наследовать"). При этом сами микромодули обеспечат множественность экземпляров, сделанных по общей заготовке ("подобие").

В принципе сама идея исходит из простых вещей: в Обероне "класс" в отличие от мэйнстрим-языков разбит на "тип" и "модуль". Модуль в Обероне самодостаточен. Тип - также. Но если внутри одного модуля в Обероне можно держать разные классы и пользоваться преимуществами такого использования (принцип No Paranoia), то почему нельзя вкладывать в модуль другие модули (микромодули), которые будут чем-то похожи на классы, но при этом совсем не обязаны отвечать жестким соглашениям ООП?

Таким образом, расширяемые RECORD-типы смогут не только имитировать в Обероне классы (что уже хорошо известно), но и имитировать модули. Памятуя, что Оберон можно рассматривать как ассемблер ООП (я бы назвала - ассемблер расширяемых типов), имеет смысл поизучать возможности различных композиций применительно к реальной потребности в generic-вещах.

Ответ на »сообщение 2267« (Снегурочка)
___________________________
Интересная идея...

Ответ на »сообщение 2264« (Снегурочка)
___________________________

Кстати, некоторые вещи "подобия" заложены в классическом Обероне:

Теоретически от этого можно отталкиваться для построения своих generic-модулей. Что такое модуль в понимании Оберона? Помимо того, что в языке это основное  средство инкапсуляции программных  сущностей (область видимости, область существования), которое использует механизм экспорта-импорта, модуль еще и контейнер сущностей: "конкретных" (констант, переменных, процедур) и "порождающих" (типов, "классов" - т.е. некоторых из расширяемых RECORD-типов).

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

Раз микромодуль - это RECORD-структура, ее можно экспортировать-импортировать и расширять ("наследовать"). При этом сами микромодули обеспечат множественность экземпляров, сделанных по общей заготовке ("подобие").