Предлагаю пересмотреть стандартные макросы с целью ухода от статических полей для хранения промежуточных данных.
Возможно стоит предварительно сделать какие-то инструменты для упрощения работы со свойством UserData классов MangerClass-а и TypeBuilder-а?

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

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

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

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

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

Закройте баг плиз. Я его пофиксил, хотя и не через UserData. Не знал о нем просто.

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

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

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

Может сделать макру.

  internal module Helper
  {
    [UserDataStore]
    public mutable AdditionalLoggingCondition : PExpr = null;
  }

которая будет заменять поле на свойство и работать через Manager.UserData["_N_Nemerle.Logging.Helper.AdditionalLoggingCondition"]?

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

H>Предлагаю пересмотреть стандартные макросы с целью ухода от статических полей для хранения промежуточных данных.
H>Возможно стоит предварительно сделать какие-то инструменты для упрощения работы со свойством UserData классов MangerClass-а и TypeBuilder-а?

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

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

Что касается несовместимости некоторых макросов с IDE, то это еще более глубокий вопрос — вопрос проектирования макросов с учетом особенностей работы в IDE. Макросы которые писали поляки точно нужно править. Если у кого-то есть врем и желание, займитесь этим.

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

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

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

H>>Предлагаю пересмотреть стандартные макросы с целью ухода от статических полей для хранения промежуточных данных.
H>>Возможно стоит предварительно сделать какие-то инструменты для упрощения работы со свойством UserData классов MangerClass-а и TypeBuilder-а?

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

Я тоже когда-то пришел к этому выводу.

Вот примерный вариант бэкэнда к макросу:

[MacroUsage(MacroPhase.BeforeTypedMembers, MacroTargets.Field)]
macro SomeMacro(tb : TypeBuilder, fb : ParsedField) {
    def backend = SomeMacroBackend(tb);
    backend.DoWork(fb);
}

[MacroBackend]
class SomeMacroBackend {

    [ManagerProperty] x : int = 10; // изготавливает строго типизированное свойство
                                    // для словаря Manager.UserData

    [TypeBuilderProperty] t : string = 100;  // изготавливает строго типизированное свойство
                                             // для TypeBuilder.UserData
                                             // наличие хотябы одного такого свойства
                                             // приводит к необходимости передавать в конструктор
                                             // инстанс TypeBuilder (а если их нет то и передавать не надо)

    public DoWork(fb : PT.ClassMember.Field) : void {
        // свойства:
        //   Manager - текущий инстанс ManagerClass
        //   TypeBuilder - текущий билдер (если нужен)
    }
}

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

H>Вот примерный вариант бэкэнда к макросу:...

Может быть тогда проще все же ввести эти самые макросы-классы?

На мой взгляд выглядеть это должно как-то так:

macro class SomeName : IMacroAtribut[ClassMember.Field]
{
  [ManagerProperty]     x : int = 10;
  [TypeBuilderProperty] t : string = 100;

  Transform(fb : ClassMember.Field) : void
  {
    ...
  }
}

macro class SomeName : IExpressionMacro
{
  Transform(fb : PExpr) : PExpr
  {
    ...
  }
}

Подпачитать парсер ведь не так сложно. Главное реализацию накатать...

Может займешься?

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

VD>Подпачитать парсер ведь не так сложно. Главное реализацию накатать...

VD>Может займешься?

Звучит крайне брутально...

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

VD>>Подпачитать парсер ведь не так сложно. Главное реализацию накатать...

VD>>Может займешься?

H>Звучит крайне брутально...

Что тут брутальношго? Просто серьезная задача для серьезных людей.

Подсистему парсинга макросов давно надо было бы причесать. Ее явно лепили еще в самом начале и с тех пор не рефакторили.

Реализовать указанный синтаксис будет не сложно. Фактически нужно просто проверить не идет ли за ключевым словом "macro" ключевое слово "class" и если идет, то вызвать стандартный код парсинга типа. Ну, а когда он вернет АСТ класса, то уже поколдовать над ним и сгенерирвоать то что требуется для макросов.