[API] Наш ответ рослину?
От: catbert  
Дата: 19.10.11 22:12
Оценка: 18 (1)
http://blogs.msdn.com/b/kirillosenkov/archive/2011/10/18/roslyn-ctp.aspx

Вот с чего и надо копировать API
Re: [API] Наш ответ рослину?
От: Кирилл Осенков Украина
Дата: 20.10.11 01:12
Оценка:
У нашего API ещё далеко не всё гладко. Вот например код для изменения узла в дереве:

        [TestMethod]
        public void UpdateNode()
        {
            string text = "class C { void M() { } }";
            var tree = SyntaxTree.ParseCompilationUnit(text);
            var root = (CompilationUnitSyntax)tree.Root;
            MethodDeclarationSyntax method = root
                .DescendentNodes()
                .OfType<MethodDeclarationSyntax>()
                .First();
            var newMethod = method.Update(
                method.Attributes,
                method.Modifiers,
                method.ReturnType,
                method.ExplicitInterfaceSpecifierOpt,
                Syntax.Identifier("NewMethodName"),
                method.TypeParameterListOpt,
                method.ParameterList,
                method.ConstraintClauses,
                method.BodyOpt,
                method.SemicolonTokenOpt);

            root = root.ReplaceNode(method, newMethod);
            tree = SyntaxTree.Create(tree.FileName, root, tree.Options);
            Assert.AreEqual("class C { void NewMethodName() { } }", tree.Text.GetText());
        }


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

Вот такие интересные проблемы возникают с immutable деревьями.
Re: [API] Наш ответ рослину?
От: Ziaw Россия  
Дата: 20.10.11 01:38
Оценка:
Здравствуйте, catbert, Вы писали:

C>http://blogs.msdn.com/b/kirillosenkov/archive/2011/10/18/roslyn-ctp.aspx


C>Вот с чего и надо копировать API


Теперь есть хороший бэкенд, ответом должен быть хороший фронтэнд. N2 можно стартовать.
Re[2]: [API] Наш ответ рослину?
От: Ziaw Россия  
Дата: 20.10.11 02:45
Оценка: 9 (1)
Здравствуйте, Кирилл Осенков, Вы писали:

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


Можно сделать хелпер на экспрешенах, по аналогии с bltoolkit linq Update. Будет не оптимально быстро, но для внешнего пользователя подойдет. Он все равно компиляторы не пишет.
Re[2]: [API] Наш ответ рослину?
От: WolfHound  
Дата: 20.10.11 04:39
Оценка: 20 (2)
Здравствуйте, Кирилл Осенков, Вы писали:

КО>Вот такие интересные проблемы возникают с immutable деревьями.

В функциональном программировании есть свои паттерны.
И чтобы не было мучительно больно их нужно изучить, прежде чем делать неизменяемые деревья.
В данном случае zipper вас спасет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: [API] Наш ответ рослину?
От: Кирилл Осенков Украина
Дата: 20.10.11 05:42
Оценка:
WH>В функциональном программировании есть свои паттерны.
WH>И чтобы не было мучительно больно их нужно изучить, прежде чем делать неизменяемые деревья.
WH>В данном случае zipper вас спасет.

Спасибо, постараюсь разобраться. К своему стыду, абсолютно с этим не знаком.

У каждого паттерна есть область применимости. Т.е. проблема которую он решает, ситуация (или условия), в которой этот паттерн хорошо работает. Просто так тулить паттерны на проблему не глядя смысла не имеет. Будет очень интересно, если бы ты смог рассказать поподробнее, когда нужно и когда не нужно использовать zipper. В идеале если бы был пример эффективной реализации в управляемой среде типа CLR или Java. И чтобы память жрало по минимуму.

У нас (в примере, который я привёл) проблема не с реализацией, а с дизайном API. Собственно реализацию мы сделали и вроде она нашим требованиям удовлетворяет. Мы оптимизировали реализацию на производительность, исходя из GC allocations, memory traffic и пр. особенности .NET платформы. Заменили в нужных местах классы на структуры, сделали внутренние деревья без ссылок на родителей (для переиспользования) и пр.

Т.е. проблема у нас в данном случае — как сделать юзабельный API surface. Какой наименее лаконичный и discoverable код юзер должен написать, чтобы изменить данное свойство данного неизменяемого узла? Один из вариантов, который мы рассматривали, это нагенерировать кучу методов MethodDeclarationSyntax.SetAttributes(..), MethodDeclarationSyntax.ClearAttributes(..), MethodDeclarationSyntax.SetModifiers(..) и пр. которые возвращают новый экземпляр MethodDeclarationSyntax.

Ну Fluent API то есть.

Хотелось сделать, чтобы был один метод с optional parameters (указывать аргументы только для тех параметров, которые хочется изменить). Но всё упирается в то, что в CLR нету nullable reference типов. Кстати, ещё один вариант рассматривали — сделать Option<T> (ну типа Maybe), но у него с очевидностью не очень.

Вот. Будет интересно послушать любые соображения. Повторюсь, я от функциональных паттернов не отнекиваюсь. За первые 10 минут я не разобрался, как zipper применить для нашей проблемы. Буду разбираться дальше, но любая дополнительная помощь очень приветствуется. На первый взгляд кажется что нам хранить "текущий элемент" (дырку, или как они говорят, фокус) не нужно. Т.к. заранее неизвестно какое свойство узла пользователь будет менять.
Re[2]: [API] Наш ответ рослину?
От: dotneter  
Дата: 20.10.11 06:17
Оценка:
Здравствуйте, Кирилл Осенков, Вы писали:

Вопрос в сторону, посмотрел документацию то так и не понял, можно ли с помощью Roslyn сделать подобие макроатрибутов?
... << RSDN@Home 1.2.0 alpha 5 rev. 1536>>
Talk is cheap. Show me the code.
Re[2]: [API] Наш ответ рослину?
От: catbert  
Дата: 20.10.11 06:43
Оценка: +1
Здравствуйте, Кирилл Осенков, Вы писали:

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


Я бы добавил методы .WithAttributes, .WithName, .WithXxx, которые возвращают новый объект, но с измененным свойством.
Re[3]: [API] Наш ответ рослину?
От: Ziaw Россия  
Дата: 20.10.11 06:49
Оценка:
Здравствуйте, dotneter, Вы писали:

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


D>Вопрос в сторону, посмотрел документацию то так и не понял, можно ли с помощью Roslyn сделать подобие макроатрибутов?


А какие проблемы? Код переписывать можно. Берем обычные атрибуты, ищем их в коде и меняем дерево так как нужно.

Надо просто сделать Roslyn.Nemerle, который предоставит нормальный DSL для всего этого (квазицитаты и PM).
Re[3]: [API] Наш ответ рослину?
От: Кирилл Осенков Украина
Дата: 20.10.11 07:14
Оценка:
Z>Можно сделать хелпер на экспрешенах, по аналогии с bltoolkit linq Update. Будет не оптимально быстро, но для внешнего пользователя подойдет. Он все равно компиляторы не пишет.

Интересно, но перформанс нужен... Этот способ слишком расточительный, да и по API usability не очень.
Re[3]: [API] Наш ответ рослину?
От: Кирилл Осенков Украина
Дата: 20.10.11 07:16
Оценка:
C>Я бы добавил методы .WithAttributes, .WithName, .WithXxx, которые возвращают новый объект, но с измененным свойством.
Да, это похоже самый лучший вариант.
Re[4]: [API] Наш ответ рослину?
От: dotneter  
Дата: 20.10.11 07:17
Оценка:
Здравствуйте, Ziaw, Вы писали:

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


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


D>>Вопрос в сторону, посмотрел документацию то так и не понял, можно ли с помощью Roslyn сделать подобие макроатрибутов?


Z>А какие проблемы? Код переписывать можно. Берем обычные атрибуты, ищем их в коде и меняем дерево так как нужно.

Вот я не увидел, где можно взять код допустим метода и переписать, везде работают со строками.
... << RSDN@Home 1.2.0 alpha 5 rev. 1536>>
Talk is cheap. Show me the code.
Re[2]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.10.11 11:34
Оценка:
Здравствуйте, Кирилл Осенков, Вы писали:

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


Дык, вообще-то, не надо было null за допустимое значение принимать. Сделайте кучу dummy-объектов и назовите их None.

А вообще, тут по-уму нужно язык изменять. Во-первых, было бы разумно ввести в язык возможность здания в качестве значения по умолчанию любых выражений. Просто сериалиппзовать дерево разбора этого выражения и в сериализованной форме подставлять в атрибут хранящий значение по умолчанию. В Скале это реализовано. Я давно хотел для немерла это сделать, но времени не хватает.

Во-вторых, можно было бы сделать фичу аналогичную F#-овской. Во многих МЛ-языках (в том числе и в F#) есть синтаксис для изменения неизменяемых структур. Для шарпа его можно было бы адаптировать как-то так:
MethodDeclarationSyntax  method = ...;
MethodDeclarationSyntax  newMethod  = new method {  Name = Syntax.Identifier("NewMethodName"); }


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

Только одним этим ваши проблемы не решаться. Чтобы использовать рослин для метапрограммирования или рефакторинга еще нужны человеческие средства декомпозиции (распознования) кода. То что сделали вы — это очень неудобно. Тут нужно квазицитирование и удобный доступ к типизированному представлению.

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

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

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

Кстати, чтобы показать вашему руководству полезность МП можно было бы сделать нужные вам расширения языка как препроцессор (на рослине же). Например, вот такая вот конструкция:
MethodDeclarationSyntax  newMethod  = new method {  Name = Syntax.Identifier("NewMethodName"); }

совершенно корректна с точки зрения синтаксиса шарпа, но не с точки зрения его семантики, так как за new должен идти тип.
Но что стоит сделать легкий препроцессор который бы заменял бы эту конструкцию на то что ты привел в своем сообщении?
Правильно — ничего. Все что нужно знать — это то что method не является типом. А это как раз не сложно вычислить (при вашей то семантической системе).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.10.11 11:34
Оценка:
Здравствуйте, Кирилл Осенков, Вы писали:

КО>Хотелось сделать, чтобы был один метод с optional parameters (указывать аргументы только для тех параметров, которые хочется изменить). Но всё упирается в то, что в CLR нету nullable reference типов. Кстати, ещё один вариант рассматривали — сделать Option<T> (ну типа Maybe), но у него с очевидностью не очень.


С очевидностью у него все ОК. Вот с производительностью проблемы. Если только структурой делать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.10.11 11:44
Оценка:
Здравствуйте, catbert, Вы писали:

C>http://blogs.msdn.com/b/kirillosenkov/archive/2011/10/18/roslyn-ctp.aspx


C>Вот с чего и надо копировать API


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

Средства конструирования новых сущностей и декомпозиция там тоже не на высоте.

Есть так же вещи которые для меня выглядят загадочно. АПИ их вроде как имьютабельный, но под капотом тварится какая-то химия. Реальные данный АСТ-веток получаются из слотов. Что за Green Red я вообще не понял. Подозреваю, что это какая-то оптимизация удешевления неизменяемости.

Кстати, хотелось бы услышать от Киралиа, что это за химия и зачем она нужна.

Но кое-чему поучиться можно. Одна только смелость с которой они практически все (включая Solution) сделали неизменяемым заслуживает уважения!

Качество и проработка тоже на высоте.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.10.11 11:45
Оценка:
Здравствуйте, Ziaw, Вы писали:

D>>Вопрос в сторону, посмотрел документацию то так и не понял, можно ли с помощью Roslyn сделать подобие макроатрибутов?


Z>А какие проблемы?


Отсутствие точки входа. Ты же не будешь свои проекты компилировать собственной версией компилятора? И уж точно не захочешь, чтобы они не могли работать в IDE (ведь движок интеграции о твоих расширения знать не будет).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.10.11 11:47
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Надо просто сделать Roslyn.Nemerle, который предоставит нормальный DSL для всего этого (квазицитаты и PM).


Это будет другой язык. Для него опять же нужно от печки клепать всю инфраструктуру.

Было бы куда лучше, если бы они сразу заложили нужные точки входа. Например, в виде событий.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.10.11 11:49
Оценка:
Здравствуйте, dotneter, Вы писали:

D>Вот я не увидел, где можно взять код допустим метода и переписать, везде работают со строками.


Переписать то как раз можно. Это они сделали. Вот как получить доступ к АСТ во время компиляции, пока не ясно. Боюсь, что ни как.

Еще одна проблема — они полностью закрыли АПИ типизации. Создать объекты семантической модели можно только изнутри компилятора (они все интерналом помечены). А было бы куда лучше, если бы это апи так же было доступно для прямого конструирования. Тогда мы бы без труда навернули немрл (точнее уже свой язык) поверх рослина.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.10.11 11:50
Оценка:
Здравствуйте, Кирилл Осенков, Вы писали:

C>>Я бы добавил методы .WithAttributes, .WithName, .WithXxx, которые возвращают новый объект, но с измененным свойством.

КО>Да, это похоже самый лучший вариант.

От перегрузок будет рябить в глазах. Лучше чуть расширить язык.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: [API] Наш ответ рослину?
От: WolfHound  
Дата: 20.10.11 11:55
Оценка:
Здравствуйте, Кирилл Осенков, Вы писали:

КО>У каждого паттерна есть область применимости. Т.е. проблема которую он решает, ситуация (или условия), в которой этот паттерн хорошо работает. Просто так тулить паттерны на проблему не глядя смысла не имеет. Будет очень интересно, если бы ты смог рассказать поподробнее, когда нужно и когда не нужно использовать zipper.

Этот паттерн используется для навигационного доступа и "редактирования" неизменяемых структур.

КО>В идеале если бы был пример эффективной реализации в управляемой среде типа CLR или Java. И чтобы память жрало по минимуму.

Устройство функциональных языков не так уж и отличается от CLR и Java.
Так что я думаю, что можно брать любой пример на строгом языке. Nemerle, OCaml, F#,...
Ленивые языки типа хаскеля это отдельная история. Примеры на них вам не подойдут. Разве что на интерфейс посмотреть.
Вот простенький пример на F#: http://www.lshift.net/blog/2010/12/30/f-zipper-with-pipe-forward
Вот еще интересная статья на эту тему: http://www.cs.tufts.edu/~nr/pubs/zipcfg-abstract.html
Там народ сделал оптимизатор С-- на зипперах.

КО>У нас (в примере, который я привёл) проблема не с реализацией, а с дизайном API.

Это я понял.

КО>Собственно реализацию мы сделали и вроде она нашим требованиям удовлетворяет. Мы оптимизировали реализацию на производительность, исходя из GC allocations, memory traffic и пр. особенности .NET платформы. Заменили в нужных местах классы на структуры, сделали внутренние деревья без ссылок на родителей (для переиспользования) и пр.

Короче занимались тем, чем занимаются функциональщики не первое десятилетие.

КО>Т.е. проблема у нас в данном случае — как сделать юзабельный API surface. Какой наименее лаконичный и discoverable код юзер должен написать, чтобы изменить данное свойство данного неизменяемого узла? Один из вариантов, который мы рассматривали, это нагенерировать кучу методов MethodDeclarationSyntax.SetAttributes(..), MethodDeclarationSyntax.ClearAttributes(..), MethodDeclarationSyntax.SetModifiers(..) и пр. которые возвращают новый экземпляр MethodDeclarationSyntax.

Это тоже вариант.
Но он работает только для текущей ветки.
И ее потом придется, каким то образом засунуть обратно в дерево.
Вот это выглядит весьма сомнительно. Особенно если дерево глубокое и нужно поменять несколько методов.
root = root.ReplaceNode(method, newMethod);


КО>Вот. Будет интересно послушать любые соображения. Повторюсь, я от функциональных паттернов не отнекиваюсь. За первые 10 минут я не разобрался, как zipper применить для нашей проблемы. Буду разбираться дальше, но любая дополнительная помощь очень приветствуется. На первый взгляд кажется что нам хранить "текущий элемент" (дырку, или как они говорят, фокус) не нужно. Т.к. заранее неизвестно какое свойство узла пользователь будет менять.

Фокус нужно хранить на тот элемент свойства, которого хочешь поменять.
А у этого фокуса уже сделать методы типа SetModifiers.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.10.11 12:07
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Теперь есть хороший бэкенд, ответом должен быть хороший фронтэнд. N2 можно стартовать.


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

Остается только генерировать дерево разбора шарпа (у них оно называется SyntaxTree, далее для простоты, буду называть его АСТ). Но тут тоже вылезут свои проблемы. Основная — это то, что рослин будет повтрно, и о своим правилам производить типизацию сгенерированного АСТ. А это означает, что АСТ должно быть однозначным. Но описать однозначное в рслин нельзя.

Например, вот как у них выглядит АСТ вызова функции/метода:
    //     Class which represents the syntax node for invocation expression.
    public sealed class InvocationExpressionSyntax : ExpressionSyntax
    {
        //     ArgumentListSyntax node representing the list of arguments of the invocation
        //     expression.
        public ArgumentListSyntax ArgumentList { get; }

        //     ExpressionSyntax node representing the expression part of the invocation.
        public ExpressionSyntax Expression { get; }

        public InvocationExpressionSyntax Update(ExpressionSyntax expression, ArgumentListSyntax argumentList);
    }

Очевидно, что Expression не позволяет задать вызываемую функцию однозначно. Ведь в шарпе даже нет возможности указать тип (сигнатуру) функции (нет даже такого понятия).

Вот если бы в МС помогли бы нам и ввели еще одну ветку АСТ (или расширили InvocationExpressionSyntax), так чтобы кроме выражения можно было бы так же четко задать сигнатуру функции которую нужно вызвать, то нам было бы проще.

А так остается только попытаться помочь рослину поставив перед каждым выражением аргумента по явному приведению типов (и надеяться на то что в таких условиях его вывод типов будет работать как надо).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.10.11 12:13
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>И ее потом придется, каким то образом засунуть обратно в дерево.

WH>Вот это выглядит весьма сомнительно. Особенно если дерево глубокое и нужно поменять несколько методов.
WH>
WH>root = root.ReplaceNode(method, newMethod);
WH>


КО>>Вот. Будет интересно послушать любые соображения. Повторюсь, я от функциональных паттернов не отнекиваюсь. За первые 10 минут я не разобрался, как zipper применить для нашей проблемы. Буду разбираться дальше, но любая дополнительная помощь очень приветствуется. На первый взгляд кажется что нам хранить "текущий элемент" (дырку, или как они говорят, фокус) не нужно. Т.к. заранее неизвестно какое свойство узла пользователь будет менять.

WH>Фокус нужно хранить на тот элемент свойства, которого хочешь поменять.
WH>А у этого фокуса уже сделать методы типа SetModifiers.

Как я понял они реализовали что-то вроде зипера (внутри). Реально все свойства АСТ выглядят так:
public sealed class MemberAccessExpressionSyntax : ExpressionSyntax
{
  // Fields
  private ExpressionSyntax expression;
  private SimpleNameSyntax name;

  // Methods
  internal MemberAccessExpressionSyntax(SyntaxNode parent, SyntaxNode green, int position) : base(parent, green, position)
  {
  }

  internal override void Accept(SyntaxVisitor visitor)
  {
    visitor.VisitMemberAccessExpression(this);
  }

  internal override TResult Accept<TResult>(SyntaxVisitor<TResult> visitor)
  {
    return visitor.VisitMemberAccessExpression(this);
  }

  internal override SyntaxNode GetCachedSlot(int index)
  {
    switch (index)
    {
      case 0:
        return this.expression;

      case 2:
        return this.name;
    }
    return null;
  }

  internal override SyntaxNode GetNodeSlot(int index)
  {
    switch (index)
    {
      case 0:
        return base.GetRed<ExpressionSyntax>(ref this.expression, 0);

      case 2:
        return base.GetRed<SimpleNameSyntax>(ref this.name, 2);
    }
    return null;
  }

  public MemberAccessExpressionSyntax Update(ExpressionSyntax expression, SyntaxToken operatorToken, SimpleNameSyntax name)
  {
    if (((expression == this.Expression) && !(operatorToken != this.OperatorToken)) && (name == this.Name))
    {
      return this;
    }
    MemberAccessExpressionSyntax node = Syntax.MemberAccessExpression(base.Kind, expression, operatorToken, name);
    SyntaxAnnotation[] annotations = base.GetAnnotations();
    if ((annotations != null) && (annotations.Length > 0))
    {
      return node.WithAnnotations<MemberAccessExpressionSyntax>(annotations);
    }
    return node;
  }

  // Properties
  public ExpressionSyntax Expression
  {
    get
    {
      return base.GetRed<ExpressionSyntax>(ref this.expression, 0);
    }
  }

  public SimpleNameSyntax Name
  {
    get
    {
      return base.GetRed<SimpleNameSyntax>(ref this.name, 2);
    }
  }

  public SyntaxToken OperatorToken
  {
    get
    {
      return new SyntaxToken(this, (SyntaxToken) base.Green.GetSlot(1), this.GetChildPosition(1), base.GetChildIndex(1));
    }
  }
}
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: [API] Наш ответ рослину?
От: Kpoxa http://kuklaora.blogspot.com
Дата: 20.10.11 14:10
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Еще одна проблема — они полностью закрыли АПИ типизации. Создать объекты семантической модели можно только изнутри компилятора (они все интерналом помечены). А было бы куда лучше, если бы это апи так же было доступно для прямого конструирования. Тогда мы бы без труда навернули немрл (точнее уже свой язык) поверх рослина.


Так тож ctp.
Может попробовать пообщаться с авторами?
Re[7]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.10.11 14:18
Оценка:
Здравствуйте, Kpoxa, Вы писали:

VD>>Еще одна проблема — они полностью закрыли АПИ типизации. Создать объекты семантической модели можно только изнутри компилятора (они все интерналом помечены). А было бы куда лучше, если бы это апи так же было доступно для прямого конструирования. Тогда мы бы без труда навернули немрл (точнее уже свой язык) поверх рослина.


K>Так тож ctp.


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

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

K>Может попробовать пообщаться с авторами?


Гы. А мы тут что делаем? Кирил Осенков и есть человек из команды Рослина.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: [API] Наш ответ рослину?
От: catbert  
Дата: 20.10.11 14:53
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>От перегрузок будет рябить в глазах. Лучше чуть расширить язык.


Не думаю, что будет страшнее, чем System.Windows.Forms.Form.

А язык расширить — да, лучше
Re[6]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.10.11 15:01
Оценка:
Здравствуйте, catbert, Вы писали:

C>Не думаю, что будет страшнее, чем System.Windows.Forms.Form.


На код генерируемый дизайнером форм смотреть обычно не приходится. Да и не так уж он страшен (хотя сам дизайнер еще то прикол).

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

В прочем всяко лучше чем сейчас.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: [API] Наш ответ рослину?
От: Ziaw Россия  
Дата: 20.10.11 15:16
Оценка:
Здравствуйте, dotneter, Вы писали:

Z>>А какие проблемы? Код переписывать можно. Берем обычные атрибуты, ищем их в коде и меняем дерево так как нужно.

D>Вот я не увидел, где можно взять код допустим метода и переписать, везде работают со строками.

Ну как же, прямо по ссылке в исходном посте есть пример:

[TestMethod]
public void TransformTreeUsingSyntaxRewriter()
{
    string text = "class C { void M() { } int field; }";
    SyntaxTree tree = SyntaxTree.ParseCompilationUnit(text);
    SyntaxNode newRoot = new RemoveMethodsRewriter().Visit(tree.Root);
    Assert.AreEqual("class C { int field; }", newRoot.GetFullText());
}


Я еще не копался, но RemoveMethodsRewriter визитор по дереву выражений, удаляющий некий метод.
Re[6]: [API] Наш ответ рослину?
От: dotneter  
Дата: 20.10.11 15:51
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Я еще не копался, но RemoveMethodsRewriter визитор по дереву выражений, удаляющий некий метод.

Это и есть работа со строкой.
Вопрос, можно ли сделать
class Foo { void M() { } int field; }
SyntaxTree.Parse(typeof(Foo));
И что бы потом еще все изменения залить опять в Foo
... << RSDN@Home 1.2.0 alpha 5 rev. 1536>>
Talk is cheap. Show me the code.
Re[7]: [API] Наш ответ рослину?
От: hardcase Пират http://nemerle.org
Дата: 20.10.11 15:56
Оценка:
Здравствуйте, dotneter, Вы писали:

D>И что бы потом еще все изменения залить опять в Foo


Это всетаки не JavaScript
/* иЗвиНите зА неРовнЫй поЧерК */
Re[7]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.10.11 16:03
Оценка:
Здравствуйте, dotneter, Вы писали:

D>Это и есть работа со строкой.

D>Вопрос, можно ли сделать
D>class Foo { void M() { } int field; }
D>SyntaxTree.Parse(typeof(Foo));
D>И что бы потом еще все изменения залить опять в Foo

Нет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.10.11 16:05
Оценка:
Здравствуйте, dotneter, Вы писали:

Z>>Я еще не копался, но RemoveMethodsRewriter визитор по дереву выражений, удаляющий некий метод.

D>Это и есть работа со строкой.

Строка там парсится и дальнешая работа ведется с АСТ. Ты выидимо хочешь что-то вроде квази-цитат. Этого нет и не предвидится.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: [API] Наш ответ рослину?
От: dotneter  
Дата: 20.10.11 17:03
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Z>>>Я еще не копался, но RemoveMethodsRewriter визитор по дереву выражений, удаляющий некий метод.

D>>Это и есть работа со строкой.

VD>Строка там парсится и дальнешая работа ведется с АСТ. Ты выидимо хочешь что-то вроде квази-цитат. Этого нет и не предвидится.

Квази цитирование для конструирования аст, меня же интересует собственно возможность реализовать того же механизм что и у немерла, в момент копляции как то получить аст объекта что бы его трансформировать.
... << RSDN@Home 1.2.0 alpha 5 rev. 1536>>
Talk is cheap. Show me the code.
Re[9]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.10.11 17:19
Оценка:
Здравствуйте, dotneter, Вы писали:

D>Квази цитирование для конструирования аст, меня же интересует собственно возможность реализовать того же механизм что и у немерла, в момент копляции как то получить аст объекта что бы его трансформировать.


Ну, вот я и говорю — нет и (видмо) не предвидится.

Вот давайте вместе просить тех кто делает Рослин хотя бы о том, чтобы их АПИ позволило без траха встроить нужную функциональность самостоятельно.

Мы подумываем об использовании рослика как бэкэнда для немерла.

Ну, а если бы дали точки входа, то (с большой вероятностью) можно было бы и к шарпу удобную метасистему прикрутить (но бещ расширения синтаксиса).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: [API] Наш ответ рослину?
От: dotneter  
Дата: 20.10.11 17:38
Оценка:
Здравствуйте, VladD2, Вы писали:

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


D>>Квази цитирование для конструирования аст, меня же интересует собственно возможность реализовать того же механизм что и у немерла, в момент копляции как то получить аст объекта что бы его трансформировать.


VD>Ну, вот я и говорю — нет и (видмо) не предвидится.


VD>Вот давайте вместе просить тех кто делает Рослин хотя бы о том, чтобы их АПИ позволило без траха встроить нужную функциональность самостоятельно.


Если они за пять лет разработки сами не додумались, я сомневаюсь что там может что то поменяться.
... << RSDN@Home 1.2.0 alpha 5 rev. 1536>>
Talk is cheap. Show me the code.
Re[11]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.10.11 18:07
Оценка:
Здравствуйте, dotneter, Вы писали:

D>Если они за пять лет разработки сами не додумались, я сомневаюсь что там может что то поменяться.


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

Где-то событие добавить. Где-то чуть расширить структуры данных. Где-то типы пабличными (вместо интернал) следать. А в результате компайлер-эс-сервисес превратится из пиара в реальность.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [API] Наш ответ рослину?
От: Ziaw Россия  
Дата: 20.10.11 18:14
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я вчера смотрел рослин на этот предмет. Выводы не совсем утешительные. Типизированный апи (который там называется SemanticModel) полностью закрыт. Сгенерировать свое типизированное дерево (а, скорее всего, именно с него генерируется код) извне невозможно. Не уверен, но возможно, что SemanticModel плотно привязан к парс-три и без него просо не будет работаь. А это вообще ошибка дизайна, на мой взгляд.


Это семантическая модель C#. Думаю вообще не стоит использовать Roslyn.Compilers.CSharp, а только Roslyn.Compilers. Там бэкэнды по генерации кода и чтению метаданных (в том числе и CCI). Ну и всякие интересные для парсера/компилятора типы данных.

Правда там тоже:
[assembly: InternalsVisibleTo("Roslyn.Compilers.CSharp")]



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

VD>Остается только генерировать дерево разбора шарпа (у них оно называется SyntaxTree, далее для простоты, буду называть его АСТ). Но тут тоже вылезут свои проблемы. Основная — это то, что рослин будет повтрно, и о своим правилам производить типизацию сгенерированного АСТ. А это означает, что АСТ должно быть однозначным. Но описать однозначное в рслин нельзя.


VD>Очевидно, что Expression не позволяет задать вызываемую функцию однозначно. Ведь в шарпе даже нет возможности указать тип (сигнатуру) функции (нет даже такого понятия).


VD>А так остается только попытаться помочь рослину поставив перед каждым выражением аргумента по явному приведению типов (и надеяться на то что в таких условиях его вывод типов будет работать как надо).


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

Обидно другое, скорость компиляции упадет еще сильнее. Так что генерация AST шарпа вариант интересный (в том числе и тем, что можно компилировать прямо в исходный код, этого многие хотели), но надо очень хорошо подумать перед выбором этого направления.
Re[10]: [API] Наш ответ рослину?
От: WolfHound  
Дата: 20.10.11 18:25
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Мы подумываем об использовании рослика как бэкэнда для немерла.

Тут не все так просто.
Нужно еще будет выяснить под какой это все лицензией.
Ибо если нельзя будет использовать немерле под моно на линухе то оно того не стоит.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: [API] Наш ответ рослину?
От: Ziaw Россия  
Дата: 20.10.11 18:36
Оценка:
Здравствуйте, dotneter, Вы писали:

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


Z>>Я еще не копался, но RemoveMethodsRewriter визитор по дереву выражений, удаляющий некий метод.

D>Это и есть работа со строкой.
D>Вопрос, можно ли сделать
D>class Foo { void M() { } int field; }
D>SyntaxTree.Parse(typeof(Foo));
D>И что бы потом еще все изменения залить опять в Foo

Ничего не понял. Какой typeof(Foo) на этапе компиляции Foo.cs?

Код парсится в АСТ, АСТ скармливается компилятору. Между парсером и компилятором можно вклиниться, но стандартных механизмов для этого нет, надо писать свою обертку к компилятору. Чем больше я смотрю на сборки рослина, тем больше вижу, что все возможности расширения закрыты в очень многих местах и это не радует .
Re[5]: [API] Наш ответ рослину?
От: Ziaw Россия  
Дата: 20.10.11 18:41
Оценка:
Здравствуйте, VladD2, Вы писали:

Z>>Надо просто сделать Roslyn.Nemerle, который предоставит нормальный DSL для всего этого (квазицитаты и PM).


VD>Это будет другой язык. Для него опять же нужно от печки клепать всю инфраструктуру.


Ну конечно, это будет N2. Для него и так надо все клепать почти от печки.

VD>Было бы куда лучше, если бы они сразу заложили нужные точки входа. Например, в виде событий.


Куда заложили, в комиплятор C#? Если добавим туда МП, то похерим nemerle. Только вот, когда я пишу на шарпе, я не только по МП скучаю.
Re[11]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.10.11 20:07
Оценка:
Здравствуйте, WolfHound, Вы писали:

VD>>Мы подумываем об использовании рослика как бэкэнда для немерла.

WH>Тут не все так просто.
WH>Нужно еще будет выяснить под какой это все лицензией.

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

WH>Ибо если нельзя будет использовать немерле под моно на линухе то оно того не стоит.


Речь не идет о полном переходе на это дело. Но как один из бэкэндов его использоать будте можно. Причем это нам гарантирует, что код скомплированный на немерле можно будет запустить на любой платформе где будет работать код скомпилированный на шарпе.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.10.11 20:08
Оценка:
Здравствуйте, Ziaw, Вы писали:

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


Ну, открыть то всегда будет можно... если с дизайном сейчас не накосячат.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.10.11 20:10
Оценка:
Здравствуйте, Ziaw, Вы писали:

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


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

А так, скорее всего, как бэкэнд мы его использовать сможем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.10.11 20:14
Оценка:
Здравствуйте, 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 шарпа вариант интересный (в том числе и тем, что можно компилировать прямо в исходный код, этого многие хотели), но надо очень хорошо подумать перед выбором этого направления.


Думаю, что скорость сильно не просядет. Мы же будем предоставлять однозначный АСТ. А раз так, то там не чему будет тормозить. Так что нужно свой вывод типов подтягивать. Тогда скорость будет на уровне.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: [API] Наш ответ рослину?
От: Аноним  
Дата: 22.10.11 06:59
Оценка: 18 (1) +1
Здравствуйте, Кирилл Осенков, Вы писали:

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


var newMethod = method.Update( UpdateFlags.Attributes | UpdateFlags.Modifiers,
                attributes : myAttributes,
                modifiers : myModifiers);
Re[3]: [API] Наш ответ рослину?
От: Ziaw Россия  
Дата: 22.10.11 17:59
Оценка:
Здравствуйте, Аноним, Вы писали:

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


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


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


Почти, только достаточно одного флага.
Re[4]: [API] Наш ответ рослину?
От: Аноним  
Дата: 24.10.11 08:24
Оценка:
Здравствуйте, Ziaw, Вы писали:

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


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


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


Почему одного? Чего-то не доходит.
Re[5]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.10.11 10:13
Оценка:
Здравствуйте, Аноним, Вы писали:

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


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

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

Если менять надо одно свойство, то зачем задавать множество параметров?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: [API] Наш ответ рослину?
От: Аноним  
Дата: 24.10.11 10:55
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


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

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

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


Так в этом примере меняются 2 свойства.
Флаги должны задаваться по одному флагу на каждое свойство, которое меняется.
Re[5]: [API] Наш ответ рослину?
От: Ziaw Россия  
Дата: 24.10.11 11:42
Оценка:
Здравствуйте, Аноним, Вы писали:

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


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


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


Достаточно сделать флаг, что дефолтные значения аргументов рассматриваются как "оставить старые".
Re[6]: [API] Наш ответ рослину?
От: Аноним  
Дата: 24.10.11 12:29
Оценка:
Здравствуйте, Ziaw, Вы писали:

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


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


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


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


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


Этим способом нельзя будет пользоваться, если существует хоть малейшая возможность, что один из передаваемых аргументов будет иметь значение null.
Re[7]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.10.11 14:22
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Так в этом примере меняются 2 свойства.

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

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

Все надо делать просто, как можно проще, но не проще. (с)
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: [API] Наш ответ рослину?
От: Аноним  
Дата: 24.10.11 14:49
Оценка:
Здравствуйте, VladD2, Вы писали:

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


А>>Так в этом примере меняются 2 свойства.

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

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


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


Это как раз тот случай.
Либо надо указывать все аргументы, либо только часть.
В случае использования отдельных методов для изменения свойств объекта по одному, будут порождаться лишние объекты.
В случае использования одного флага (дефолтные значения рассматриваются как оставить старые) мы имеем проблемы с установкой null.
Поэтому без изменения синтаксиса языка это самый компактный способ.
Согласен, что выглядит не очень. Но по мне все остальное еще хуже.
Re[9]: [API] Наш ответ рослину?
От: Аноним  
Дата: 24.10.11 15:10
Оценка:
Здравствуйте, Аноним, Вы писали:

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


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


Здесь класс MethodChanges не иммутабельный, а внутри реализована логика, отслеживающая какие свойства заданы.
Минус — создание объекта на пустом месте.
Заранее согласен, что тоже не очень.
Но все-таки лучше, чем указывать все аргументы явно.
Re[9]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.10.11 15:19
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Это как раз тот случай.

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

+1, КО

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


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

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


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

А>Поэтому без изменения синтаксиса языка это самый компактный способ.

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

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

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

ЗЫ

А основывать API на null-ах как допустимых значениях — это по любому плохо. Я бы на месте рослиновцев, пока не поздно, подрефакторил API и выкинул бы из него использование null в качестве значения. Тогда бы и null можно было использовать без опасений, и в других местах проверок не лепить. Ведь null же он везде может вылезти. И никто не сможет гарантировать, что он всегда будет по делу.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: [API] Наш ответ рослину?
От: matumba  
Дата: 18.09.12 20:56
Оценка:
Здравствуйте, Кирилл Осенков, Вы писали:

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

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

Зачем вам неизменяемость в принципе? Для _облегчения_ параллельной обработки. А что мешает тупо "лочить" обрабатываемую ветку на время изменений? Тогда вместо смехотворных и громоздких ДавайтеПоменяемИмя().АТеперьПоменяемАтрибут() надо будет только заблокировать ветку и заменить объект.
Re[3]: [API] Наш ответ рослину?
От: nikov США http://www.linkedin.com/in/nikov
Дата: 19.09.12 00:01
Оценка:
Здравствуйте, matumba, Вы писали:

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

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

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


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

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

* Рефакторинги c preview
* Анализаторы кода, которым нужен ответ на вопрос "а что будет, если сделать так ..."
* Паралельный байндинг и анализ кода
* Асинхронный Find All References
и многое другое...
Re[4]: [API] Наш ответ рослину?
От: matumba  
Дата: 19.09.12 08:21
Оценка:
Здравствуйте, 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


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

Я всё же не допираю до изначальной проблемы (вот с этой громоздкой штуковиной по изменению узла). Залочить ветку, заменить узел, разлочить — это не подходит? (сами же говорите про независимость веток — т.е. каждую ветку атомарно корёжит свой процесс)
Re[5]: [API] Наш ответ рослину?
От: nikov США http://www.linkedin.com/in/nikov
Дата: 19.09.12 23:23
Оценка:
Здравствуйте, matumba, Вы писали:

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


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

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


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


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

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


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

Рекомендую ещё посмотреть эту тему: http://www.rsdn.ru/forum/decl/3300824.1
Автор: thesz
Дата: 21.02.09
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.