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

Z>Чем больше я смотрю на сборки рослина, тем больше вижу, что все возможности расширения закрыты в очень многих местах и это не радует .

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

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

Z>Куда заложили, в комиплятор C#? Если добавим туда МП, то похерим nemerle. Только вот, когда я пишу на шарпе, я не только по МП скучаю.

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

А так, скорее всего, как бэкэнд мы его использовать сможем.

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

Z>Это семантическая модель C#. Думаю вообще не стоит использовать Roslyn.Compilers.CSharp, а только Roslyn.Compilers.

А смысл? В Roslyn.Compilers одни базовые классы. Это будет закат солнца вручную. С тем же успехом можно самим все сделать.

Генерировать код умеет только конеретный компилятор (Roslyn.Compilers.CSharp, например).

Z>Там бэкэнды по генерации кода и чтению метаданных (в том числе и CCI). Ну и всякие интересные для парсера/компилятора типы данных.

Z>Правда там тоже:
Z>

Z>[assembly: InternalsVisibleTo("Roslyn.Compilers.CSharp")]
Z>

Z>

Во как? Ну, это вообще ни в какие ворота не лезет. Офигительный такой открытый АПИ.
Для ВБ такой же атрибутик есть?

Z>Что может помешать ее использовать в самых неожиданных местах.

+1

Z>Видимо ты имел ввиду разрешение перегрузок, а не вывод типов?

Ну, почему же? Я имело в виду именно вывод типов. Разрешение перегрузки — это его часть.

Z>Если есть сигнатура полностью подходящая под типы параметров — она и будет выбрана, без вариантов. То есть да, для реализации перегрузок немерла аргументы должны быть типизированы им же.

Не все так очевидно как кажется. Есть там подводные камни.

Z>Обидно другое, скорость компиляции упадет еще сильнее. Так что генерация AST шарпа вариант интересный (в том числе и тем, что можно компилировать прямо в исходный код, этого многие хотели), но надо очень хорошо подумать перед выбором этого направления.

Думаю, что скорость сильно не просядет. Мы же будем предоставлять однозначный АСТ. А раз так, то там не чему будет тормозить. Так что нужно свой вывод типов подтягивать. Тогда скорость будет на уровне.

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

КО>Очень уж громоздко. Вот думаем, как изменить Update() чтобы не передавать все параметры. Если сделать optional, тогда как присвоить свойству null? Т.е. непонятно, если передавать null, это очистка или "оставь как было"?

var newMethod = method.Update( UpdateFlags.Attributes | UpdateFlags.Modifiers,
                attributes : myAttributes,
                modifiers : myModifiers);

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

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

КО>>Очень уж громоздко. Вот думаем, как изменить Update() чтобы не передавать все параметры. Если сделать optional, тогда как присвоить свойству null? Т.е. непонятно, если передавать null, это очистка или "оставь как было"?

А>

А>var newMethod = method.Update( UpdateFlags.Attributes | UpdateFlags.Modifiers,
А>                attributes : myAttributes,
А>                modifiers : myModifiers);
А>

Почти, только достаточно одного флага.

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

Z>Здравствуйте, Аноним, Вы писали:

А>>

А>>var newMethod = method.Update( UpdateFlags.Attributes | UpdateFlags.Modifiers,
А>>                attributes : myAttributes,
А>>                modifiers : myModifiers);
А>>

Z>Почти, только достаточно одного флага.

Почему одного? Чего-то не доходит.

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

А>>>

А>>>var newMethod = method.Update( UpdateFlags.Attributes | UpdateFlags.Modifiers,
А>>>                attributes : myAttributes,
А>>>                modifiers : myModifiers);
А>>>

Z>>Почти, только достаточно одного флага.
А>Почему одного? Чего-то не доходит.

Если менять надо одно свойство, то зачем задавать множество параметров?

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

VD>Здравствуйте, Аноним, Вы писали:

А>>>>

А>>>>var newMethod = method.Update( UpdateFlags.Attributes | UpdateFlags.Modifiers,
А>>>>                attributes : myAttributes,
А>>>>                modifiers : myModifiers);
А>>>>

Z>>>Почти, только достаточно одного флага.
А>>Почему одного? Чего-то не доходит.

VD>Если менять надо одно свойство, то зачем задавать множество параметров?

Так в этом примере меняются 2 свойства.
Флаги должны задаваться по одному флагу на каждое свойство, которое меняется.

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

А>>>

А>>>var newMethod = method.Update( UpdateFlags.Attributes | UpdateFlags.Modifiers,
А>>>                attributes : myAttributes,
А>>>                modifiers : myModifiers);
А>>>

Z>>Почти, только достаточно одного флага.

А>Почему одного? Чего-то не доходит.

Достаточно сделать флаг, что дефолтные значения аргументов рассматриваются как "оставить старые".

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

Z>Здравствуйте, Аноним, Вы писали:

А>>>>

А>>>>var newMethod = method.Update( UpdateFlags.Attributes | UpdateFlags.Modifiers,
А>>>>                attributes : myAttributes,
А>>>>                modifiers : myModifiers);
А>>>>

Z>>>Почти, только достаточно одного флага.

А>>Почему одного? Чего-то не доходит.

Z>Достаточно сделать флаг, что дефолтные значения аргументов рассматриваются как "оставить старые".

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

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

А>Так в этом примере меняются 2 свойства.
А>Флаги должны задаваться по одному флагу на каждое свойство, которое меняется.

А зачем эти флаги? Это что-то из серии жутких интерфейсов WinAPI. Не как не забуду как день искал ошибку, а потом оказалось, что просто в поле флагов была грязь.

Все надо делать просто, как можно проще, но не проще. (с)

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

VD>Здравствуйте, Аноним, Вы писали:

А>>Так в этом примере меняются 2 свойства.
А>>Флаги должны задаваться по одному флагу на каждое свойство, которое меняется.

VD>А зачем эти флаги? Это что-то из серии жутких интерфейсов WinAPI. Не как не забуду как день искал ошибку, а потом оказалось, что просто в поле флагов была грязь.

VD>Все надо делать просто, как можно проще, но не проще. (с)

Это как раз тот случай.
Либо надо указывать все аргументы, либо только часть.
В случае использования отдельных методов для изменения свойств объекта по одному, будут порождаться лишние объекты.
В случае использования одного флага (дефолтные значения рассматриваются как оставить старые) мы имеем проблемы с установкой null.
Поэтому без изменения синтаксиса языка это самый компактный способ.
Согласен, что выглядит не очень. Но по мне все остальное еще хуже.

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

Еще как вариант:

var newMethod = method.Update(new MethodChanges { Attributes = myAttributes, Modifiers = myModifiers});

Здесь класс MethodChanges не иммутабельный, а внутри реализована логика, отслеживающая какие свойства заданы.
Минус — создание объекта на пустом месте.
Заранее согласен, что тоже не очень.
Но все-таки лучше, чем указывать все аргументы явно.

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

А>Это как раз тот случай.
А>Либо надо указывать все аргументы, либо только часть.

+1, КО

А>В случае использования отдельных методов для изменения свойств объекта по одному, будут порождаться лишние объекты.

Если надо менять только одно поле, то нет. Но согласен, способ менее универсальный.

А>В случае использования одного флага (дефолтные значения рассматриваются как оставить старые) мы имеем проблемы с установкой null.

Откровенно говоря за дизайн с нулами как допустимыми значениями мне уже их АПИ не нравится.

А>Поэтому без изменения синтаксиса языка это самый компактный способ.
А>Согласен, что выглядит не очень. Но по мне все остальное еще хуже.

А по мне так и Option[T], и Dummy-объекты все же по лучше будут. Да и вообще нужно отказываться от Optianal-полей в пользу создания отдельных ветвей AST. Например, вместо одного IfSyntax (не помню как он точно называется) сделать два. Они для if без else. А другой с else. И сразу проблема отпадает.

Хотя я бы голосовал за новый синтаксис.

ЗЫ

А основывать API на null-ах как допустимых значениях — это по любому плохо. Я бы на месте рослиновцев, пока не поздно, подрефакторил API и выкинул бы из него использование null в качестве значения. Тогда бы и null можно было использовать без опасений, и в других местах проверок не лепить. Ведь null же он везде может вылезти. И никто не сможет гарантировать, что он всегда будет по делу.

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

КО>У нашего API ещё далеко не всё гладко. Вот например код для изменения узла в дереве:
КО>Очень уж громоздко.
КО>Вот такие интересные проблемы возникают с immutable деревьями.

Зачем вам неизменяемость в принципе? Для _облегчения_ параллельной обработки. А что мешает тупо "лочить" обрабатываемую ветку на время изменений? Тогда вместо смехотворных и громоздких ДавайтеПоменяемИмя().АТеперьПоменяемАтрибут() надо будет только заблокировать ветку и заменить объект.

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

КО>>У нашего API ещё далеко не всё гладко. Вот например код для изменения узла в дереве:
КО>>Очень уж громоздко.
КО>>Вот такие интересные проблемы возникают с immutable деревьями.

M>Зачем вам неизменяемость в принципе? Для _облегчения_ параллельной обработки. А что мешает тупо "лочить" обрабатываемую ветку на время изменений? Тогда вместо смехотворных и громоздких ДавайтеПоменяемИмя().АТеперьПоменяемАтрибут() надо будет только заблокировать ветку и заменить объект.

http://en.wikipedia.org/wiki/Persistent_data_structure

Существенно облегчает следующие вещи:

* Рефакторинги c preview
* Анализаторы кода, которым нужен ответ на вопрос "а что будет, если сделать так ..."
* Паралельный байндинг и анализ кода
* Асинхронный Find All References
и многое другое...

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

N>http://en.wikipedia.org/wiki/Persistent_data_structure

Странно, но они говорят несколько о другой вещи: "data structure that always preserves the previous version of itself when it is modified". Т.е. ключевое слово — "версионность", про "неизменяемость" вообще речи не идёт. Что же конкретно поддерживается в Roslyn??

(кстати, так и не было ответа на вопрос Влада что такое "красное" и "зелёное" — мне тоже стало интересно )

N>Существенно облегчает следующие вещи:

N>* Рефакторинги c preview

Звучит интересно, но никакого "preview" я в студии не наблюдаю — просто переименовываю поле и вижу результат. Не понравилось — откатываю. Но этот "откат" можно рассматривать и как "отрефактори со старыми величинами" — никакой версионности не требуется. Более того — если уж я решаюсь на рефатокринг, как правило его не откатываю.

N>* Анализаторы кода, которым нужен ответ на вопрос "а что будет, если сделать так ..."

Хех... и много таких в регулярной работе?

N>* Паралельный байндинг и анализ кода

Да пожалуйста! Распараллель и обрабатывай. Каждый проц — свою подветку.

N>* Асинхронный Find All References

Ридонли поиск — чего ему страшиться? ЛЮБОЕ дерево взял и пробежался.

Я всё же не допираю до изначальной проблемы (вот с этой громоздкой штуковиной по изменению узла). Залочить ветку, заменить узел, разлочить — это не подходит? (сами же говорите про независимость веток — т.е. каждую ветку атомарно корёжит свой процесс)

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

M>Звучит интересно, но никакого "preview" я в студии не наблюдаю — просто переименовываю поле и вижу результат. Не понравилось — откатываю. Но этот "откат" можно рассматривать и как "отрефактори со старыми величинами" — никакой версионности не требуется. Более того — если уж я решаюсь на рефатокринг, как правило его не откатываю.

Когда открывается smart tag с несколькими опциями, то перемещая фокус по ним, можно сразу видеть preview результата во всплывающем окошке (и в нем, кстати, тоже работает анализ ошибок и подсветки).

N>>* Анализаторы кода, которым нужен ответ на вопрос "а что будет, если сделать так ..."

M>Хех... и много таких в регулярной работе?

Постоянно. Хотя бы подсветка избыточных приведений типа, using директив и других вещей.

M>Я всё же не допираю до изначальной проблемы (вот с этой громоздкой штуковиной по изменению узла). Залочить ветку, заменить узел, разлочить — это не подходит? (сами же говорите про независимость веток — т.е. каждую ветку атомарно корёжит свой процесс)

Локи плохо подходят для многопоточной асинхронной работы с синтаксическими деревьями. Уже достаточно намучились с дедлоками, рэйскондишенами, данными которые кто-то поменял и забыл откатить и другими прелестями. Неизменяемые структуры данных рулят.

Рекомендую ещё посмотреть эту тему: http://www.rsdn.ru/forum/decl/3300824.1

Автор: thesz
Дата: 21.02.09