Здравствуйте, VladD2, Вы писали:

VD>Кстати, ты уже ведь пару месяцев с на нем пишешь. Так?

Чуток поболее (с начала этого года).

VD>Может поделишся впечатлениями после того как немного разобрался в конкурерующей компонентной среде. Очень интересно что ты думашь теперь.

0) У меня есть сонмище претензий к Си-образному синтаксиссу, инструкции goto, break, continue и т.п.; дополнительно к Exceptions и много чему еще, но думаю, Вы вовсе не об этом хотели бы тут сейчас услышать.

1) Отсутсвие явного синтаксического определения модуля и соответственно явного синтаксически зафиксированного импорта модулей:

Нет возможности глядя на текст Namespace1.Ident1 понять в каком модуле определена сущность Ident1. В обероне же, запись Module1.Ident1 сразу делает понятным в каком модуле определена сущность Ident1. Вот, например, сейчас у меня solution состоит из полусотни модулей (сборок). Я то сам пока помню в каком модуле какая сущность описана, но человек со стороны или я через некоторое время просто глядя на текст Namespace1.Ident1 как пойму в каком из модулей искать определение сущности Ident1?

Глядя на текст модуля не видно какие модули он импортирует. Для этого надо использовать вспомогательный tool, а именно заглядывать в view -> solution explorer -> (project) references

Что если в одном модуле есть сущность по имени A.B.C, где B — это namespace, а в другом модуле есть точно так же обозванная другая сущность где B — это class? А вот при наличии явно синтаксически определённого понятия модуля подобных коллизий быть не может.

2) Модульная загадка про константу.

Автор: Сергей Губанов
Дата: 01.07.05

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

3) Нет полноценных value-type: 1) от struct — наследовать нельзя, 2) массивы только ссылочные.

4) При фантастически огромном обилии синтаксического сахара почему-то нет такого простого синтаксического сахара как самые обычные процедуры, вместо них надо заводить sealed class с private конструктором в котором уже писать static методы. Это немного странно: этому дала, этому дала, а этому не дала...

5) Замечание к недоделкам и странностям в VS 2003:
Вот у меня в solution есть полсотня модулей. Теперь в одном из них я сделал изменение в интерфейсе. Делаю Rebuild Solution — ребилдится преспокойно (хотя не должна — интерфейс же поменял), другие модули импортирующие первый не видят изменений в изменённом модуле. Для того чтобы другие модули увидели изменения надо 1) Выключить VS 2003; 2) Вручную стереть все папки с именем obj; 3) Запустить VS 2003 и только после этого сделать Rebuild Solution — вот тогда другие модули увидят изменения.