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

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

VD>>Любой представитель мэйнстрима может написать Визетер для этого дела

AVK>И визитер в сотню, если не больше, узлов, да еще без контроля со стороны компилятора, придется, как я понимаю, писать ручками?

Ну а как ты хотел? Посмотри на объектную модель Рефлектора или на тот же Expression линка, там тоже классов не две штуки

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

AVK>И визитер в сотню, если не больше, узлов, да еще без контроля со стороны компилятора, придется, как я понимаю, писать ручками?

А вообще авоматический Визитор у нас сейчас есть (ага, на макросе . Его текущая задача — сбор синтаксических ошибок во всем CompilationUnit-е.
Если кому-то нужно что-то еще этот механизм всегда можно задействовать.

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

AVK>И визитер в сотню, если не больше, узлов, да еще без контроля со стороны компилятора,

"Визитер без контроля со стороны компилятора" — это ты замечательно ляпнул. Но лучше такое при людях знающих этот паттерн не говорить. За смеют.

AVK>придется, как я понимаю, писать ручками?

Это обратно пропорционально коэффициенту интеллекта того кто будет писать. При IQ ниже среднего, конечно, без ручной работы не обойтись. Если интеллекта чуть по более, становятся доступны рефлексия и T4. При IQ чуть выше среднего можно пользоваться Nemerle и паттер-матчингом (но тут еще, конечно, придется не дюжую смелость проявить).

Мне казалось, что твоего IQ должно быть достаточно, чтобы оценить объемы ручной работы по приведенному куску года.

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

_FR>>А можно что-либо сделать (на сколько это принципиально и как крепко прибито), что бы имена полей получались бы в UpperCase или в виде private readonly-полей и public-свойств? За это отвечает описание граматики (то есть достаточно переписать граматику парсера C#) или компилятор Немерле?

H>Я пока не вижу пракического смысла в таком переписывании. Объекты всеравно иммутабельные.

Есть широко известны гайдлайны, которые регламентируют, с использованием какого кейса предподчтительно называть открытые поля типов. Жаль, если разработчики библиотеки Немерле не принимают их врасчёт.

По поводу свойств — именно на свойствах работает, например, такой механизм как дефолтовый TypeDescriptionProvider, который позволяет биндится (то есть отображать в UI значения) к свойствам объекта. Написать свой, предоставляющий поля, конечно можно. Но readonly поле и public get свойство неизменяемости повредить не сможет, а вот и гайдлайнам удовлетворит и лучшую поддержку фреймворка и прочих библиотек обеспечит.

Причём тут вообще IQ, я даже при очень большом желании использовать немерл не смогу пробить стену мэнеджмента который справедливо боится что поддержка сего проекта закончится сразу после того как кто то не ухватится за новую супер пупер идею, как это было с R#

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

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

_FR>>>А можно что-либо сделать (на сколько это принципиально и как крепко прибито), что бы имена полей получались бы в UpperCase или в виде private readonly-полей и public-свойств? За это отвечает описание граматики (то есть достаточно переписать граматику парсера C#) или компилятор Немерле?

H>>Я пока не вижу пракического смысла в таком переписывании. Объекты всеравно иммутабельные.

_FR>Есть широко известны гайдлайны, которые регламентируют, с использованием какого кейса предподчтительно называть открытые поля типов. Жаль, если разработчики библиотеки Немерле не принимают их врасчёт.

А еще variant-ов нет в .NET. Они из ML-я приехали. — это по повду кейсов.
Конечно, вопрос (и свойствами тоже) этот решаемый, и я прекрасно представляю как. Но пока никому не нужно было столь плотно работать с вариантами из C# и тем более, отображать их на интерфейсе.

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

H>А еще variant-ов нет в .NET. Они из ML-я приехали. — это по повду кейсов.

Ну и что? Под кейсами я понимаю UpperCase и LowerCase. И variant есть не что иное как всего лишь понятие языка. Гайдлайны как раз позволяют единообразно использовать типы в рамках платформы.

H>Конечно, вопрос (и свойствами тоже) этот решаемый, и я прекрасно представляю как. Но пока никому не нужно было столь плотно работать с вариантами из C# и тем более, отображать их на интерфейсе.

Странно, что он небыл решён в самом начале. Майкрософт уже со времён второго фреймворка успешно избегает public instance fields в своих типах.

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

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

H>>А еще variant-ов нет в .NET. Они из ML-я приехали. — это по повду кейсов.

_FR>Ну и что? Под кейсами я понимаю UpperCase и LowerCase. И variant есть не что иное как всего лишь понятие языка. Гайдлайны как раз позволяют единообразно использовать типы в рамках платформы.

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

H>>Конечно, вопрос (и свойствами тоже) этот решаемый, и я прекрасно представляю как. Но пока никому не нужно было столь плотно работать с вариантами из C# и тем более, отображать их на интерфейсе.

_FR>Странно, что он небыл решён в самом начале. Майкрософт уже со времён второго фреймворка успешно избегает public instance fields в своих типах.

Во фреймворке нет вариантных классов, как и паттерн матчинга усложнять и без того непростую логику никому было не нужно.
Опять же проблем из-за public instance полей никто не имел.

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

H>>>А еще variant-ов нет в .NET. Они из ML-я приехали. — это по повду кейсов.
_FR>>Ну и что? Под кейсами я понимаю UpperCase и LowerCase. И variant есть не что иное как всего лишь понятие языка. Гайдлайны как раз позволяют единообразно использовать типы в рамках платформы.
H>Я тоже под ними понимаю регистр написания идентификаторов.
H>Проблема в том, что шаблоны паттерн матчинга обладают неоднозначностью и именование полей варианты в нижнем регистре позволяет ее разрешать (это у нас by design).

То есть, если поля варинтов буду названы в верхнем регистре, что-то (паттерн-матчинг) в Немерле работать не будет? Неужели это так? Можно пример посмотреть?

H>>>Конечно, вопрос (и свойствами тоже) этот решаемый, и я прекрасно представляю как. Но пока никому не нужно было столь плотно работать с вариантами из C# и тем более, отображать их на интерфейсе.
_FR>>Странно, что он небыл решён в самом начале. Майкрософт уже со времён второго фреймворка успешно избегает public instance fields в своих типах.
H>Во фреймворке нет вариантных классов, как и паттерн матчинга усложнять и без того непростую логику никому было не нужно.
H>Опять же проблем из-за public instance полей никто не имел.

Это, конечно, весомые аргументы

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

_FR>То есть, если поля варинтов буду названы в верхнем регистре, что-то (паттерн-матчинг) в Немерле работать не будет? Неужели это так? Можно пример посмотреть?

Это так. В противном случае будет неразрешимый на уровне парсера конфликт:

| something => ...

something — это что? Конструктор или просто переменная?

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

H>Я тоже под ними понимаю регистр написания идентификаторов.
H>Проблема в том, что шаблоны паттерн матчинга обладают неоднозначностью и именование полей варианты в нижнем регистре позволяет ее разрешать (это у нас by design).

Это у вас кривой design значит, если написав идентификатор в другом регистре получаешь другое поведение. Вы пишете сперва под .Net и уже потом на Nemerle. Любые другие приоритеты делают вас закрытым клубом.

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

VD>Это обратно пропорционально коэффициенту интеллекта того кто будет писать. При IQ ниже среднего, конечно, без ручной работы не обойтись. Если интеллекта чуть по более, становятся доступны рефлексия и T4. При IQ чуть выше среднего можно пользоваться Nemerle и паттер-матчингом (но тут еще, конечно, придется не дюжую смелость проявить).

Влад, ну причём тут интеллект? C# и T4 официально поддерживаемые продукты, Nemerle — нет. Вне зависимости от конкретного положения дел, стоящего за словами "официально поддерживаемый" менеджменту сложно согласиться использовать Nemerle. Я понимаю, что ситуация как в анекдоте "Не трахают, потому прыщи. Прыщи, потому не трахают.", но это реальность.

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

A>Это у вас кривой design значит, если написав идентификатор в другом регистре получаешь другое поведение. Вы пишете сперва под .Net и уже потом на Nemerle. Любые другие приоритеты делают вас закрытым клубом.

Т.е. то, что в AST используются поля и называются они в нижнемРегистре делает невозможным работу с ним?

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

VD>>Ага. AST там именно в таком виде. Но варианты реализованы на базе классов. Вот как выглядит AST в Рефлекторе:
_FR>

VD>>    [VariantOption]
VD>>    public sealed class Alias : Expr
VD>>    {
VD>>        // Fields
VD>>        public readonly Identifier id;
_FR>

_FR>А можно что-либо сделать (на сколько это принципиально и как крепко прибито), что бы имена полей получались бы в UpperCase или в виде private readonly-полей и public-свойств? За это отвечает описание граматики (то есть достаточно переписать граматику парсера C#) или компилятор Немерле?

Это поля вариантов. Для вариантов есть свои гайдлайны и свои правила. Причем, в отличии от правил форматирования эти правила влияют на работу паттерн-матчинга.

Вариантный тип — это не просто класс. Если присмотреться к коду по внимательнее, то можно заметить, что описание полей полностью совпадают с описанием параметров одного из конструкторов. Это не случайно! В это есть большой смысл. Немерл гарантирует это. В результате мы можем в распозновать объекты вариантных типов типов с помощью образцов описывающих конструктор такого типа. Скажем, конкретный экземпляр Alias-а можно распознать таким образом:

match (ast)
{
  | Alias(id) => WriteLine(id);
  ... // другие образцы
}

По этому если сделать имена полей с большой буквы, то с большой буквы будут и имена параметров конструкторов. Это еще хуже соотносится с гайдлайнами.

Конечно можно сгенерировать (причем автоматически) свойства дублирующие эти поля. Но на мой взгляд — это все вкусовщина на которую не стоит тратить время. Плюс дублирование сущностей (поля и свойства будут мало чем отличаться) не есть гуд.

Так что если нужно ехать, а не шашечки лучше переступить через свои привычки и все будет ОК.

Ну, а еще лучше попробовать освоить немерл. Ведь распознавание АСТ в десятки раз проще осуществлять с помощью паттерн-матчинга. Немерл ничем не отличается от Шарпа по возможнсотям. И на нем можно очень просто и быстро реализовать ту логику обработки АСТ которая вам нужна. Ну, а на выходе вы можете создать DLL которая предоставляет данные или методы в полном соответствии с вашими гайдлайнами. И уже эту сборку использовать в проекте.

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

Tom>Причём тут вообще IQ, я даже при очень большом желании использовать немерл не смогу пробить стену мэнеджмента который справедливо боится что поддержка сего проекта закончится сразу после того как кто то не ухватится за новую супер пупер идею, как это было с R#
А чем опен-сорс компилятор отличается в данном случае от опен-сорс библиотеки? Тоже менеджмент использовать не разрешает, даже если можно кучу человеко-месяцев сэкономить? А как же основная работа менеджера — свои прибыли на максимум вытягивать и красивые графики клиентам показывать?

Если вы общаетесь с МС как все, через connect, и прямой линии к Хельсбергу и Co у вас нету — то поддержка которую оказывает МС де факто _хуже_ чем поддержка которую можно получить на форуме Nemerle. Кроме того у вас есть возможность и смотреть в сорцы компилятора, и в крайнем случае даже поправить самим. Код компилятора на самом деле вполне обозримого размера, именно из-за того что написан на себе-же и при сборке сам себя тестирует.

Да и никто не заставляет вас сразу хватать проект на 5 лет разработки кучей народу и всё на Nemerle. Сделайте пилотный проект, пройдите пару майлстонов и окажетесь на светлой стороне

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

_FR>Ну и что? Под кейсами я понимаю UpperCase и LowerCase. И variant есть не что иное как всего лишь понятие языка. Гайдлайны как раз позволяют единообразно использовать типы в рамках платформы.

По этому поводу ответы уже прозвучали. Повторяться не буду.

_FR>Странно, что он небыл решён в самом начале. Майкрософт уже со времён второго фреймворка успешно избегает public instance fields в своих типах.

В МС в большей части работают орлы которые или не догадываются о существовании readonly в C#, или искренне считают его рудиментом неизвестно зачем всунутым в язык.

Сейчас ситуация постепенно выправляется, но все же императивная идеология крепко засела во многих головах (и в вашей, кстати, тоже).

Меж тем никаких проблем с публичными полями нет, если, конечно, они доступны только на чтение. Более того, в таких условиях свойства просто не ясно зачем нужны.

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

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

H>Проблема в том, что шаблоны паттерн матчинга обладают неоднозначностью и именование полей варианты в нижнем регистре позволяет ее разрешать (это у нас by design).

Не, ты ошибаешся. К неоднозначностям это не приводит. Вот если бы ты назвал с большой буквы переменную в образце, то да. Но поля в принципе могут иметь названия с большой буквы.

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

H>Во фреймворке нет вариантных классов, как и паттерн матчинга усложнять и без того непростую логику никому было не нужно.

Все проще. Просто традиции брались вместе с фичами. Если клссы брались из C#, то и традиции названий для публичного API брались из шарпа, а если фича бралась из ML, то и традиции шли от туда. В конце концов они почти полностью совпадают.

H>Опять же проблем из-за public instance полей никто не имел.

Вот именно.

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

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

_FR>>То есть, если поля варинтов буду названы в верхнем регистре, что-то (паттерн-матчинг) в Немерле работать не будет? Неужели это так? Можно пример посмотреть?

ВВ>Это так.

Нет, не так.

ВВ>В противном случае будет неразрешимый на уровне парсера конфликт:

ВВ>| something => ...

ВВ>something — это что? Конструктор или просто переменная?

Просто переменная. Даже так: "| Aliase(id)" — это будет просто переменная введенная в паттерне и связанная с параметром конструктора варианта (т.е. с его соответствующим полем). И имя переменной может отличаться от имени поля.

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

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

VD>По этому если сделать имена полей с большой буквы, то с большой буквы будут и имена параметров конструкторов. Это еще хуже соотносится с гайдлайнами.

Что происходит чаще: создание объекта или обращение в его члену? Тем более что при создании имена параметров не используются, а при обращении к члену имена членов используются.

VD>Так что если нужно ехать, а не шашечки лучше переступить через свои привычки и все будет ОК.

Как ты размахнулся, привычки. Это не привычни, это номенклатура. Правила, позволяющие разным людям одни и те же вещи называть одинаково и, таким образом, понимать друг друга.

VD>В общем, надо просо понять, что Немерл имеет тотальное приемущество перед Шарпом в вопросе работы с иерархиями.

Пропаганда неуместа, время одноязычных программ давно прошло. Ты либо интегируешься, либо умираешь. Максимум на что ты можешь сегодня расчитывать — это использование твоего парсера из C#. Причём удобное использование, чтобы Nemerle не торчал из библиотеки во все стороны.

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

A>>Это у вас кривой design значит, если написав идентификатор в другом регистре получаешь другое поведение. Вы пишете сперва под .Net и уже потом на Nemerle. Любые другие приоритеты делают вас закрытым клубом.
H>Т.е. то, что в AST используются поля и называются они в нижнемРегистре делает невозможным работу с ним?

Заметно затрудняет. Плохое начало, если ты хочешь чтобы библиотеку использовали где-то ещё.