Да, причём, частично. Но я и не ставил цель реализовать SQL полностью. Я хотел описать как в принципе можно реализовывать предметно-ориентированные языки. И ещё выражения для создания таблиц потребуются в следующей статье, где мы будем генерить SQL-скрипты.
Это не совсем так. Последний релиз что ли был действительно 2 года назад. Сейчас они в основном исправляют ошибки без каких-то существенных изменений, отвечают на вопросы (хотя и с задержкой и не всегда), т.е. какая-то поддержка всё-таки есть. Но я не считаю, что это очень большая проблема.
Во-первых, я рассказываю не столько о конкретном инструменте, сколько в принципе о подходах и инструментах, которые используются в модельно-ориентированной разработке. Есть аналогичный проект — Xtext, с гораздо более мощным комьюнити, чем у EMFText, активно развивающийся. Он основан примерно на тех же идеях, что и EMFText. Можно использовать его.
Во-вторых, EMFText работает :) Ну, и что, что существенно не обновляется, свои задачи он решает :)
В-третьих, он с открытым исходным кодом, и какие-то вещи в нём можно допиливать самостоятельно. Фактически, это надстройка над ANTLR и EMF, которая сильно упрощает жизнь. Если бы его не было, то пришлось бы что-то подобное писать самостоятельно. А он уже написан.
Возвращаясь к ANTLR 3. Есть несколько вариантов. Можно забить на то, что он не поддерживается, если всё работает. Можно использовать Xtext или что-то подобное. Можно допилить поддержку ANTLR 4 самостоятельно.
Но в следующей статье нам парсер SQL вообще не понадобится. Всё это затевалось ради кодогенератора SQL, который на ANTLR никак не завязан.
Основная фича EMFText в том, что описав грамматику и метамодель языка мы получаем не только парсер, но и кодогенератор, и редактор, и заготовки для интерпретатора, отладчика.
Да, вы правы, действительно используется ANTLR 3, на который завязан EMFText :)
Грамматика описана на немного другом языке (хотя и очень похожем), поэтому существующие грамматики не подходят.
Зачем это нужно, если уже есть парсеры? Цели две. Во-первых, образовательная — показать как реализовывать языки с помощью EMFText, Xtext или чего-то подобного. Во-вторых, в следующей статье мы будем генерить SQL-код, а реализации на которые вы ссылаетесь умеют только парсить, а генерить SQL из синтаксического дерева не могут.
EMFText — это фактически ANTLR + EMF (Eclipse Modeling Framework). Разработчикам задавали вопрос, почему они не переходят на ANTLR 4. На что они ответили, что вообще такие планы есть, но особых преимуществ это не даст. Потому что EMFText не позволяет использовать напрямую значительную часть фич ANTLR. А в плане производительности они ANTLR 3 уже пропатчили.
Я реализовывал чистый SQL:2003. Хотя от скриптов на чистом SQL (которые будем генерить в следующей статье) наверное не очень много пользы. Но для демонстрации идеи нормально, допилить поддержку других диалектов уже не очень сложно.
Да, так и есть! Более того, даже одновременно разные эксперты могут называть разные критерии, альтернативы, цели и конечно по-разному их оценивать. Т. Саати приводит в своей книге пример выбора школы для сына. В роли экспертов выступали сам сын и жена Саати. Их оценки расходились, но благодаря тому что метод позволяет всё разложить по полочкам, они договорились между собой о выборе оптимальной школы.
Я не считаю желание ИТ компаний переехать в регион жадностью. Скорее, наоборот, это проявление не шаблонного взгляда на мир, желание найти конкурентные преимущества и, безусловно, это вклад в развитие региона. Слово «жадность» тут не очень уместно.
У меня ощущение, что ИТ отрасль качественно отличается от других отраслей. Но люди всё-равно воспринимают её как промышленность или сельское хозяйство. Казалось бы, столько технологий, упрощающих коммуникацию: авиатранспорт, всякие скайпы, электронные почты. В порядке бреда: вполне возможно, что долететь до другого города на самолете быстрее и дешевле, чем проехать по пробкам из одного конца Москвы в другой :)
Т.е. в ИТ издержки на коммуникации существенно ниже, чем в других отраслях. Но почему-то на зарплатах это не сказывается. Может быть с развитием 3d-проекторов (которые будут показывать заказчику аналитика), виртуальной реальности, дополненной реальности и т.п. ситуация изменится…
Насчёт маленького рынка разработчиков в регионах… Интересно, почему он маленький. Потому что их там не обучают, или потому что они оттуда уезжают. И действительно ли уезжают лучшие? Ведь, ИТшники — это достаточно интровертные люди, вот так взять и уехать куда-то для них не очень просто. Может уезжают не лучшие, а подвижные? По-моему это очень зашоренный, штампованный взгляд, что в Москву уезжают лучшие специалисты. Много ли вообще случаев, что ИТшник попробовал переехать в Москву, но не смог, потому что оказался не достаточно хорошим? Просто абсурд :) Кто решил переехать, тот и переехал, ИТшные способности тут вообще не причём. Скорее наоборот, посредственному ИТшнику найти работу в Москве проще, чем в регионе. Компаний больше, в какую-то да возьмут. Может уезжают посредственные?
Я понимаю, что задеваю «религиозные» чувства многих людей, но делаю это не ради троллинга, а чтобы показать, что в Матрице что-то не так :) Наверное все проблемы в мире от того, что люди привыкли мыслить штампами: «за мкадом нет специалистов», «лучшие уезжают в Москву», «зарплата ИТшников определяется регионом и это нормально». И никто не пытается понять действительно ли это так и если да, то почему.
Но это же распространяется не только на отношения между нанимателем и разработчиком, но и на отношения между заказчиком и владельцем ИТ-фирмы? Доход у ИТшной фирмы хоть в Москве, хоть в регионе может быть одинаковым. Это строителям, чтобы строить дом нужно непосредственно находиться на месте стройки. А у ИТшной фирмы заказчик может быть хоть на другой стороне земного шара. Т.е. потенциальный доход от местонахождения никак не зависит. Дык, зачем тогда тратить лишние деньги на аренду, зарплаты и т.п.?
Вы же сами говорите, что если доходы везде будут одинаковыми, то люди поедут туда где меньше издержки. Почему ИТ-компании этого не делают? Для них доходы не зависят от местонахождения.
Да и уровень специалистов выше (это является следствием или причиной более высоких зарплат).
Наверное, да, но это же относится и к другим специалистам? :) В Москву съезжаются лучшие водители автобусов, они управляют в среднем в 2 раза лучше (: Лучшие кассиры, которые в среднем в 2 раза лучше обслуживают клиентов, лучшие курьеры, строители, лучшие врачи, которые лечат в 2 раза лучше (:
Согласен, недвижимость (как и зарплата) в 2-3 раза дороже. Кстати, тоже интересно почему. Наверное в 2 раза более квалифицированные рабочие строят из в 2 раза более качественных материалов с помощью в 2 раза более качественных инструментов в 2 раза лучшие дома :) Ощущение какого-то сбоя в Матрице :) Это же бред, какой смысл нести такие издержки (на аренду офиса, зарплаты разработчиков, а разработчикам на ипотеку), когда эти же самые заказы можно выполнять с гораздо меньшими издержками.
А, интересно, в мире тоже такая разница в зарплатах между крупными и не очень крупными городами?.. Заказчики у ИТ-компаний (как в Москве, так и в каком-нибудь региональном миллионике) примерно одинаковые, уровень специалистов примерно одинаковый. Но почему-то в Москве зарплата автоматически в 2 раза больше. Интересно, почему ИТ-компании не расползаются по регионам, зачем им находиться в Москве?.. И, интересно, есть ли какая-то тенденция к выравниванию зарплат у ИТшников в мире?.. Ведь, это же глобальный рынок, местонахождение вообще не должно влиять на зарплату…
Спасибо за вопрос! Я бы не сказал, что он сугубо академический. Это как раз один из ключевых моментов в данном цикле статей. У большинства людей UML ассоциируется с UML-диаграммами (классов, последовательностей, деятельности и т.п.) Хотя, в действительности, спецификация UML в основном описывает семантику языка. Диаграммы до версии 2.5 там приводились в основном для пояснения, иллюстрации. UML-модель может быть представлена в виде диаграммы, в виде человеко-читаемого текста, в виде XMI-файла или как-то ещё.
Причём, с этим связана одна серьёзная проблема. Например, мы создали UML-модель в одном инструменте моделирования и хотим открыть её в другом инструменте. Для этого можно использовать формат XMI. Спецификации UML и XMI единые, модель в принципе должна открываться в любом инструменте, который реализует эти спецификации. Но спецификация UML до версии 2.5 не описывала как UML-модели могут быть представлены в виде диаграмм. И в каждом инструменте используется какая-то своя метамодель для диаграмм. Т.е. UML-модель мы сможем открыть в любом инструменте, но представление этой модели в виде диаграммы придётся перерисовывать. Потому что UML-модель не содержит информацию о размере и расположении квадратиков и т.п.
Т.е. в случае с UML есть две метамодели:
1) «семантическая», которая содержит такие метаклассы как Class, Actor, Activity и т.п.
2) метамодель UML-диаграмм — UML Diagram Interchange (см. приложение B), которая содержит такие матаклассы как UMLDiaram, UMLDiagramElement, UMLLabel и т.п.
Когда я говорю о метамодели UML, я конечно имею в виду 1-ую. О разнице между этими двумя метамоделями я упоминал начиная с 1-ой статьи:
Если вы понимаете о чём идет речь, то до понимая того что такое метамодели вам остается ещё один шаг – понять чем являются прямоугольники и линии на диаграммах, и понять чем является xmi-файл с точки зрения моделирования.
Потом в этой статье мы разработали «семантическую» метамодель Anchor. А в следующей статье описали для Anchor одну из возможных нотаций — в виде диаграмм.
Т.е. граница между метамоделью, описывающей семантику, и метамоделью, описывающей синтаксис языка, совершенно чёткая.
Не очень чёткий термин «язык», потому что в нём есть и синтаксические и семантические составляющие. Например, я думаю на русском языке, но это же не значит мозг оперирует наборами каких-то кириллических символов. Или если я перепишу этот текст в транслите, он же всё-равно останется русским. Для меня термин «язык» всё-таки ближе к семантике. Т.е. UML-модель — это модель описанная в терминах классов, сценариев использования, актеров и т.п. Представлена эта модель может хоть в виде диаграммы, хоть в виде текста, всё-равно она остаётся UML-моделью. Поэтому я часто ставлю знак равенства между «метамоделью UML» и «языком UML» или «метамоделью языка UML». Для меня «язык описания моделей» — это не квадратики, стрелочки, кружочки, а набор терминов, концептов (классы, актёры и т.п.). Если речь идёт именно о конкретной форме представления этих (синтаксически нейтральных) концептов, то я обычно использую термин «нотация». В моём понимании диаграммы — это одна из возможных нотаций для языка UML, но не сам язык. С другой стороны, язык без нотации существовать не может, поэтому часто нотация и язык смешиваются, с чего я и начал этот безумно длинный комментарий :)
Всем этим занимается семиотика. Есть 1) некий объект, 2) есть концепт (абстракция, возникающая в мозге, соответствующая этому объекту) и 3) знак (последовательность букв, картинка, обозначающая этот объект). Спецификация UML описывает все возможные концепты. UML Diagram Interchange описывает все возможные знаки.
Не совсем List :) Если совсем строго, то в OCL 4 вида коллекций: Bag, Set, OrderedSet, Sequence. Которые отличаются упорядоченностью и уникальностью элементов. Bag — это не упорядоченная коллекция не уникальных элементов. List ближе к Sequence.
Я и говорю, что Bag — это «некий аналог Maybe, но со своими отличиями», который вместе с операторами "." и "->" позволяет добиваться примерно того же, для чего предназначен Maybe, но проще.
Конечно, я знаю о монадах. В Haskell есть интересное обобщение монад — стрелочки :) Тип Bag, который в OCL используется для опциональных значений — это фактически и есть некий аналог Maybe, но со своими отличиями.
В OCL логика очень простая. Обычно в разных ЯП если свойство может принимать несколько значений, то для него используется какой-нибудь тип-коллекция (множество, список, массив, ...). А в OCL вообще для всех свойств, множественность которых отличается от 1, используются коллекции. В т.ч. для свойств со множественность 0..1.
На мой взгляд, это гораздо более естественный подход, чем использование null или каких-то дополнительных типов Maybe. Если свойство опциональное, значит его значения нужно представлять в виде коллекции, которая может быть либо пустой, либо синглетоном.
Если программист видит, что у свойства тип Bag, то он понимает, что значение опциональное.
Добавляем к этому два оператора для навигации "." и "->". Первый применяется к одиночным значениям, второй — к коллекциям.
И доопределяем точку и стрелочку для коллекций и единичных объектов соответственно:
1) Если точка используется для коллекции, то применяется к каждому её элементу.
2) Если стрелочка используется для единичного значения, то оно неявно преобразуется в синглетон.
Всё, получаем удобный язык без всяких Maybe, null и т.п. На самом деле, null в OCL есть, но у него немного другая роль, чем в обычных ЯП.
Чем это лучше… Например, при использовании Maybe приходится использовать явно bind, return. А в OCL это не нужно, выражения выглядят гораздо короче, понятней и естественней.
Да, очень похож! К тому же в OCL этот оператор, как и в Groovy, разворачивается в вызов операции collect.
Только, как я понял, он ведёт себя иначе для null-евых элементов списка. В OCL будет ошибка, а Groovy в результирующей коллекции сделает тоже null.
И ещё отличие, что в OCL входная и выходная коллекции оператора "." могут содержать разное количество элементов. А в Groovy, как я понимаю, они всегда равны по размеру.
«Проблема» безопасной навигации интересно решена в OCL.
Опциональные свойства имеют тип Bag (набор значений, коллекция). Если свойству не присвоено значение, то возвращается пустая коллекция. Иначе возвращается коллекция с одним значением (значением свойства).
При этом оператор "." применяется не ко всей коллекции, а к каждому элементу отдельно.
На языке OCL выражение «user.profile.thumbnails.large» будет интерпретировано так:
1) Получаем у user значение свойства profile.
1а) Если оно указано, то получаем коллекцию с этим значением,
1б) Иначе получаем пустую коллекцию.
2) Затем у каждого элемента этой коллекции обращаемся к свойству thumbnails и формируем из полученных значений новую коллекцию.
2а) Если на первом шаге получили коллекцию с одним профилем, то
2а1) Если у профиля есть thumbnail, то получаем коллекцию с иконкой этого профиля
2а2) Если у профиля thumbnail не указан, то получаем пустую коллекцию иконок
2б) Иначе (если на первом шаге получили пустую коллекцию), то и тут получаем пустую коллекцию
И т.д. Описал наверно очень туманно :) Но по-моему это идеальное решение, странно что в других языках такого нет. Нет, ещё в XPath есть, но в языках общего назначения ни разу не встречал.
Во-первых, я рассказываю не столько о конкретном инструменте, сколько в принципе о подходах и инструментах, которые используются в модельно-ориентированной разработке. Есть аналогичный проект — Xtext, с гораздо более мощным комьюнити, чем у EMFText, активно развивающийся. Он основан примерно на тех же идеях, что и EMFText. Можно использовать его.
Во-вторых, EMFText работает :) Ну, и что, что существенно не обновляется, свои задачи он решает :)
В-третьих, он с открытым исходным кодом, и какие-то вещи в нём можно допиливать самостоятельно. Фактически, это надстройка над ANTLR и EMF, которая сильно упрощает жизнь. Если бы его не было, то пришлось бы что-то подобное писать самостоятельно. А он уже написан.
Возвращаясь к ANTLR 3. Есть несколько вариантов. Можно забить на то, что он не поддерживается, если всё работает. Можно использовать Xtext или что-то подобное. Можно допилить поддержку ANTLR 4 самостоятельно.
Но в следующей статье нам парсер SQL вообще не понадобится. Всё это затевалось ради кодогенератора SQL, который на ANTLR никак не завязан.
Основная фича EMFText в том, что описав грамматику и метамодель языка мы получаем не только парсер, но и кодогенератор, и редактор, и заготовки для интерпретатора, отладчика.
Грамматика описана на немного другом языке (хотя и очень похожем), поэтому существующие грамматики не подходят.
Зачем это нужно, если уже есть парсеры? Цели две. Во-первых, образовательная — показать как реализовывать языки с помощью EMFText, Xtext или чего-то подобного. Во-вторых, в следующей статье мы будем генерить SQL-код, а реализации на которые вы ссылаетесь умеют только парсить, а генерить SQL из синтаксического дерева не могут.
EMFText — это фактически ANTLR + EMF (Eclipse Modeling Framework). Разработчикам задавали вопрос, почему они не переходят на ANTLR 4. На что они ответили, что вообще такие планы есть, но особых преимуществ это не даст. Потому что EMFText не позволяет использовать напрямую значительную часть фич ANTLR. А в плане производительности они ANTLR 3 уже пропатчили.
Я реализовывал чистый SQL:2003. Хотя от скриптов на чистом SQL (которые будем генерить в следующей статье) наверное не очень много пользы. Но для демонстрации идеи нормально, допилить поддержку других диалектов уже не очень сложно.
У меня ощущение, что ИТ отрасль качественно отличается от других отраслей. Но люди всё-равно воспринимают её как промышленность или сельское хозяйство. Казалось бы, столько технологий, упрощающих коммуникацию: авиатранспорт, всякие скайпы, электронные почты. В порядке бреда: вполне возможно, что долететь до другого города на самолете быстрее и дешевле, чем проехать по пробкам из одного конца Москвы в другой :)
Т.е. в ИТ издержки на коммуникации существенно ниже, чем в других отраслях. Но почему-то на зарплатах это не сказывается. Может быть с развитием 3d-проекторов (которые будут показывать заказчику аналитика), виртуальной реальности, дополненной реальности и т.п. ситуация изменится…
Насчёт маленького рынка разработчиков в регионах… Интересно, почему он маленький. Потому что их там не обучают, или потому что они оттуда уезжают. И действительно ли уезжают лучшие? Ведь, ИТшники — это достаточно интровертные люди, вот так взять и уехать куда-то для них не очень просто. Может уезжают не лучшие, а подвижные? По-моему это очень зашоренный, штампованный взгляд, что в Москву уезжают лучшие специалисты. Много ли вообще случаев, что ИТшник попробовал переехать в Москву, но не смог, потому что оказался не достаточно хорошим? Просто абсурд :) Кто решил переехать, тот и переехал, ИТшные способности тут вообще не причём. Скорее наоборот, посредственному ИТшнику найти работу в Москве проще, чем в регионе. Компаний больше, в какую-то да возьмут. Может уезжают посредственные?
Я понимаю, что задеваю «религиозные» чувства многих людей, но делаю это не ради троллинга, а чтобы показать, что в Матрице что-то не так :) Наверное все проблемы в мире от того, что люди привыкли мыслить штампами: «за мкадом нет специалистов», «лучшие уезжают в Москву», «зарплата ИТшников определяется регионом и это нормально». И никто не пытается понять действительно ли это так и если да, то почему.
Вы же сами говорите, что если доходы везде будут одинаковыми, то люди поедут туда где меньше издержки. Почему ИТ-компании этого не делают? Для них доходы не зависят от местонахождения.
Причём, с этим связана одна серьёзная проблема. Например, мы создали UML-модель в одном инструменте моделирования и хотим открыть её в другом инструменте. Для этого можно использовать формат XMI. Спецификации UML и XMI единые, модель в принципе должна открываться в любом инструменте, который реализует эти спецификации. Но спецификация UML до версии 2.5 не описывала как UML-модели могут быть представлены в виде диаграмм. И в каждом инструменте используется какая-то своя метамодель для диаграмм. Т.е. UML-модель мы сможем открыть в любом инструменте, но представление этой модели в виде диаграммы придётся перерисовывать. Потому что UML-модель не содержит информацию о размере и расположении квадратиков и т.п.
Т.е. в случае с UML есть две метамодели:
1) «семантическая», которая содержит такие метаклассы как Class, Actor, Activity и т.п.
2) метамодель UML-диаграмм — UML Diagram Interchange (см. приложение B), которая содержит такие матаклассы как UMLDiaram, UMLDiagramElement, UMLLabel и т.п.
Когда я говорю о метамодели UML, я конечно имею в виду 1-ую. О разнице между этими двумя метамоделями я упоминал начиная с 1-ой статьи:
Потом в этой статье мы разработали «семантическую» метамодель Anchor. А в следующей статье описали для Anchor одну из возможных нотаций — в виде диаграмм.
Т.е. граница между метамоделью, описывающей семантику, и метамоделью, описывающей синтаксис языка, совершенно чёткая.
Не очень чёткий термин «язык», потому что в нём есть и синтаксические и семантические составляющие. Например, я думаю на русском языке, но это же не значит мозг оперирует наборами каких-то кириллических символов. Или если я перепишу этот текст в транслите, он же всё-равно останется русским. Для меня термин «язык» всё-таки ближе к семантике. Т.е. UML-модель — это модель описанная в терминах классов, сценариев использования, актеров и т.п. Представлена эта модель может хоть в виде диаграммы, хоть в виде текста, всё-равно она остаётся UML-моделью. Поэтому я часто ставлю знак равенства между «метамоделью UML» и «языком UML» или «метамоделью языка UML». Для меня «язык описания моделей» — это не квадратики, стрелочки, кружочки, а набор терминов, концептов (классы, актёры и т.п.). Если речь идёт именно о конкретной форме представления этих (синтаксически нейтральных) концептов, то я обычно использую термин «нотация». В моём понимании диаграммы — это одна из возможных нотаций для языка UML, но не сам язык. С другой стороны, язык без нотации существовать не может, поэтому часто нотация и язык смешиваются, с чего я и начал этот безумно длинный комментарий :)
Всем этим занимается семиотика. Есть 1) некий объект, 2) есть концепт (абстракция, возникающая в мозге, соответствующая этому объекту) и 3) знак (последовательность букв, картинка, обозначающая этот объект). Спецификация UML описывает все возможные концепты. UML Diagram Interchange описывает все возможные знаки.
Я и говорю, что Bag — это «некий аналог Maybe, но со своими отличиями», который вместе с операторами "." и "->" позволяет добиваться примерно того же, для чего предназначен Maybe, но проще.
В OCL логика очень простая. Обычно в разных ЯП если свойство может принимать несколько значений, то для него используется какой-нибудь тип-коллекция (множество, список, массив, ...). А в OCL вообще для всех свойств, множественность которых отличается от 1, используются коллекции. В т.ч. для свойств со множественность 0..1.
На мой взгляд, это гораздо более естественный подход, чем использование null или каких-то дополнительных типов Maybe. Если свойство опциональное, значит его значения нужно представлять в виде коллекции, которая может быть либо пустой, либо синглетоном.
Если программист видит, что у свойства тип Bag, то он понимает, что значение опциональное.
Добавляем к этому два оператора для навигации "." и "->". Первый применяется к одиночным значениям, второй — к коллекциям.
И доопределяем точку и стрелочку для коллекций и единичных объектов соответственно:
1) Если точка используется для коллекции, то применяется к каждому её элементу.
2) Если стрелочка используется для единичного значения, то оно неявно преобразуется в синглетон.
Всё, получаем удобный язык без всяких Maybe, null и т.п. На самом деле, null в OCL есть, но у него немного другая роль, чем в обычных ЯП.
Чем это лучше… Например, при использовании Maybe приходится использовать явно bind, return. А в OCL это не нужно, выражения выглядят гораздо короче, понятней и естественней.
Только, как я понял, он ведёт себя иначе для null-евых элементов списка. В OCL будет ошибка, а Groovy в результирующей коллекции сделает тоже null.
И ещё отличие, что в OCL входная и выходная коллекции оператора "." могут содержать разное количество элементов. А в Groovy, как я понимаю, они всегда равны по размеру.
Если кому-то интересно, то тут спецификация OCL (раздел 7.4.10), а тут статья на русском. В OCL всего два оператора для навигации: точка "." и стрелочка "->".
Если точка применяется к объекту, то интерпретируется как и в большинстве языков типа Ruby, Java.
Если точка применяется к коллекции, то она разворачивается в оператор collect (как и в Groovy): aSet->collect(name).
Стрелочка обычно применяется к коллекции, например, чтобы посчитать сумму значений: aSet->sum()
Но если применена к одиночному объекту типа «anObject->sum()», то объект неявно кастится во множество: anObject.oclAsSet()->sum()
Таким образом в OCL выражение «user.profile.thumbnails.large» развернется в «user.profile->collect(thumbnails)->collect(large)»
Удобно то, что всего два оператора для навигации. И с пустыми множествами или синглетонами работать удобней, чем с null.
Опциональные свойства имеют тип Bag (набор значений, коллекция). Если свойству не присвоено значение, то возвращается пустая коллекция. Иначе возвращается коллекция с одним значением (значением свойства).
При этом оператор "." применяется не ко всей коллекции, а к каждому элементу отдельно.
На языке OCL выражение «user.profile.thumbnails.large» будет интерпретировано так:
1) Получаем у user значение свойства profile.
1а) Если оно указано, то получаем коллекцию с этим значением,
1б) Иначе получаем пустую коллекцию.
2) Затем у каждого элемента этой коллекции обращаемся к свойству thumbnails и формируем из полученных значений новую коллекцию.
2а) Если на первом шаге получили коллекцию с одним профилем, то
2а1) Если у профиля есть thumbnail, то получаем коллекцию с иконкой этого профиля
2а2) Если у профиля thumbnail не указан, то получаем пустую коллекцию иконок
2б) Иначе (если на первом шаге получили пустую коллекцию), то и тут получаем пустую коллекцию
И т.д. Описал наверно очень туманно :) Но по-моему это идеальное решение, странно что в других языках такого нет. Нет, ещё в XPath есть, но в языках общего назначения ни разу не встречал.