Возможно посредством стандартного макроса:

[Nemerle.MacroUsage (Nemerle.MacroPhase.BeforeInheritance, Nemerle.MacroTargets.Class, Inherited = true)] \
    macro view(tb: TypeBuilder, classname) syntax("view", classname)

изменить базовый класс типа посредством tb: TypeBuilder или другим путем (только без изменения кода компилятора ) ?

Пример применения:

Макрос должен преобразовать:

public class DemoView view DemoClass

в

public class DemoView : System.Windows.Forms.Form

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

RB>Возможно посредством стандартного макроса:

RB>

RB>[Nemerle.MacroUsage (Nemerle.MacroPhase.BeforeInheritance, Nemerle.MacroTargets.Class, Inherited = true)] \
RB>    macro view(tb: TypeBuilder, classname) syntax("view", classname)
RB>

RB>изменить базовый класс типа посредством tb: TypeBuilder или другим путем (только без изменения кода компилятора ) ?

Маловероятно. Опиши идею, может и не придется базовый класс коверкать.

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

RB>Пример применения:

RB>Макрос должен преобразовать:
RB>public class DemoView view DemoClass
RB>в
RB>public class DemoView : System.Windows.Forms.Form

А как он узнает какой именно базовый класс подставить и зачем вообще это нужно?

ie>Маловероятно. Опиши идею, может и не придется базовый класс коверкать.

Необходимо для подготовки типа представления (view type — из MVC) базовый тип хотелось менять динамически (на этапе компиляции) чтобы была возможность исходя из контекста использовать, скажем: System.Windows.Forms.Form или System.Windows.Forms.UserControl

Также прельщает то, что при желании можно будет очень легко прейти на сторонние компоненты Devexpress или VisualWebGui (изменив код в одном месте), но данный функцию легко реализовать и через промежуточный базовый класс.

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

А>Необходимо для подготовки типа представления (view type — из MVC) базовый тип хотелось менять динамически (на этапе компиляции) чтобы была возможность исходя из контекста использовать, скажем: System.Windows.Forms.Form или System.Windows.Forms.UserControl

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

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

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

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

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

А>>Необходимо для подготовки типа представления (view type — из MVC) базовый тип хотелось менять динамически (на этапе компиляции) чтобы была возможность исходя из контекста использовать, скажем: System.Windows.Forms.Form или System.Windows.Forms.UserControl

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

Вы плохого мнения о макросах Немерле .

Все можно. Даже можно старый класс убрать, а новый добавить. Вот только делать это нужно иключительно на стадии MacroPhase.BeforeInheritance. Вот за 5 минут набросал тестик...
Код макро-сборки:

using Nemerle.Compiler;
using Nemerle.Compiler.Parsetree;

namespace Test
{
    [Nemerle.MacroUsage (Nemerle.MacroPhase.BeforeInheritance, Nemerle.MacroTargets.Class, Inherited = true)]
    public macro View(tb : TypeBuilder, classname)
    syntax("view", classname)
    {
        def ast = tb.Ast :> TopDeclaration.Class;
        ast.t_extends ::= classname;
    }
}

Код тестового приложения:

using System.Console;
using Test;

class A { public Method1() : void { WriteLine("A.Method1()") } }

class B view A { }

module Program
{
  Main() : void
  {
    def b = B();
    b.Method1();    
    _ = ReadLine();
  }
}

Вся суть заключается в том, что на стадии BeforeInheritance код из AST еще не прошел этап типизации и типизированное описание не было добавлено в структуры TypeBuilder-а. AST доступно через свойство Ast (только в современной версии компилятора), так что мы можем его изменять (в том числе анализировать и выбрасывать ненужное наследовние или выдавать сообщения об ошибках если таковое присутствует).

ЗЫ

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

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

А>>>Необходимо для подготовки типа представления (view type — из MVC) базовый тип хотелось менять динамически (на этапе компиляции) чтобы была возможность исходя из контекста использовать, скажем: System.Windows.Forms.Form или System.Windows.Forms.UserControl

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

VD>Вы плохого мнения о макросах Немерле .

VD>Вся суть заключается в том, что на стадии BeforeInheritance код из AST еще не прошел этап типизации и типизированное описание не было добавлено в структуры TypeBuilder-а. AST доступно через свойство Ast (только в современной версии компилятора), так что мы можем его изменять (в том числе анализировать и выбрасывать ненужное наследовние или выдавать сообщения об ошибках если таковое присутствует).

Круто! AST — это наше все!
Только вот отдавать его пользователю — это не через чур?

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

ie>Круто! AST — это наше все!
ie>Только вот отдавать его пользователю — это не через чур?

В смысле? Кто пользователь?

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

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

VD>Вы плохого мнения о макросах Немерле .

Хочу сказать спасибо, пример с доступом к AST просто супер, особено для того кто не хочет залазить в самые дебри компилятора.
А так, как раз мение макросах самое хорошее , доступ к ядру и данным компилятора действительно позволит творить чудеса трансформации.

VD>ЗЫ

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

Вот с этим пока туго, я использую May CTP, но к сожалению отладку макросов делать невозможно (отдадка проекта в котором использовался макрос тотже не сильното работает ) — обычно возможности объектов и иследуются во время отладки, но тут уже приходится применять другой подход поиск по исходникам + информация по типам с nemerle.org.

ЗЫ

Я прекрасно понимаю что интеграция не простой проект и хочу сказать спасибо хоть за то чтон он вобше есть и развивается т.к. я считаю у nemerle очень много шансов стать мейнстримом.