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

E>>Я его по своим меркам посмотрел. Получилось пока не так здорово.

IT>Расскажи нам что не так здорово? Поделись!

Игорь, я уже говорил. Но меня здесь на смех поднимают. А роль городского сумашедшего, знаешь ли, не самая для меня привычная.

IT>Я не заметил никаких явных провокаций. Точно так можно сказать что C провоцирует писать функции с одинаковыми именами, а C++ — классы.
IT>Причём тут саппорт вообще? Если я напишу функцию Foo в моём продукте, а ты по случайному недоразумению напишешь такую же, то кому из нас её исправлять?

Это известная проблема в C и раних версиях C++. В C для нее так и не нашли исправления, придумали только workaround в виде префиксования имен функций и макросов (макросы к тому же рекомендуют большими буквами набирать). Но это все рекомендации, соблюдение которых невозможно проконтролировать. И их нарушения, как я проказал в примере с ACE, могут привести к проблемам.
В C++ эту проблему для функций и классов разрешили путем изменения языка -- добавлением пространств имен. Чтобы случился конфликт имен в разных продуктах от разных производителей при использовании пространств имен нужно постараться. Но с макросами проблема осталась. Если в библиотеке libhttp (если не ошибаюсь от W3C) есть макрос LOG_ERR, то он пересекается с моим макросом LOG_ERR и мне приходится вручную в месте каждого конфликта его разрешать какими-то очередными workaround-ами. И не всегда гарантируется, что я вовремя замечу, что пользуюсь не тем макросом.

В Nemerle с синтаксическими расширениями (после соответствующей директивы using) ситуация похожа на ситуацию с макросами в C/C++ -- если встречаются два макроса с одинаковыми именами, то разрешение этого конфликта ложится на плечи того, кто с конфликтом встретился. Но в Nemerle ситуация чуть хуже. В C/C++ макросам даже нужно давать длинные корявые имена, чтобы они сразу бросались в глаза. Поэтому в C++ нормальным именем может быть SOL4_EVENT_WITH_INCIDENT_TYPE. Но при расширении синтаксиса в язык добавляются конструкции, которые по-определению будут использоваться часто (иначе их можно было бы не вводить вообще). Поэтому и использование их должно быть удобным. А это значит, что имена новых ключевых слов должны быть короткими, емкими, лаконичными и, вероятно, общеупотребительными. В таких условиях простое event гораздо предпочтительнее, чем sol4_event_with_incident_type. Но, чем короче и общеупотребительнее имя, тем больше верятность конфликта при совместном расширении синтаксиса разными библиотеками.

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

Просто, если я соберусь делать какую-то библиотеку с расширением синтаксиса, я хочу чтобы мои пользователи имели с ней как можно меньше проблем. Введение в синтаксис таких ключевых слов, как agent, subscribe, message, priority, event конфликты с другими библиотеками может спровоцировать. А значит -- доставить проблемы. Вот и все.

При этом я не говорю и не подразумеваю, что Nemerle фуфло -- это время решит, а не я. Но вот наличие непосредственно в языке механизма, который бы просто разруливал такие конфликты мне кажется необходимым (крайне желательным, по меньшей мере). Хотябы в таком виде: в месте конфликта уточнять ключевое слово именем макропакета:

sobjectizer#agent ... sobjectizer#event ... {
  smtp#agent ... smtp#subscribe ...;
} sobjectizer#subscribe ...