Re: бинд типов в макросах
От: hardcase Пират http://nemerle.org
Дата: 12.04.10 06:01
Оценка: 12 (1)
Здравствуйте, Ziaw, Вы писали:

Z>При компиляции вылетают "Error: unbound type name 'BLToolkit.Data.Linq.Table[ Nemerle.MVC.Models.Person ]'" причем в двойном экземпляре. Как ему указать на тип? Кстати, когда я делал

Z>
Z>        t.Define(<[decl:
Z>            public $(propertyName : dyn) : BLToolkit.Data.Linq.Table[$(typeFullName : dyn)]
Z>            {
Z>              get { this.GetTable.[$(typeFullName : dyn)](); }
Z>            }
Z>        ]>);
Z>

Z>unbound был тип Nemerle.MVC.Models.Person.

typeFullName видимо имеет тип string. И он превращается в единственный PExpr.Ref, тогда как для правильного "понимания" компилятором имени типа там нужно передавать цепочку PExpr.Member (писал в браузере):
def full_name_to_expr(name : string) {
    match(NString.Split(name, ".")) {
        | [] => <[ () ]>
        | n :: [] => <[ $(n : dyn) ]>
        | n :: ns => ns.FoldLeft(<[ $(n : dyn) ]>, (n, acc) => <[ $acc.$(n : dyn) ]>)
    }
}
/* иЗвиНите зА неРовнЫй поЧерК */
Re[3]: бинд типов в макросах
От: WolfHound  
Дата: 12.04.10 11:40
Оценка: 12 (1)
Здравствуйте, Ziaw, Вы писали:

Z>Спасибо, помогло Еще вопрос, как создать из строки PExpr.Literal?

Во-первых его можно сконструировать напрямую PExpr.Literal(Nemerle.Compiler.Literal.String(str))
Во-вторых можно сделать так:
def str = "test";
<[ someMethod($(str : string)); ]>
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: бинд типов в макросах
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.04.10 19:43
Оценка: 12 (1)
Здравствуйте, Ziaw, Вы писали:

Z>И можно ли всетаки определить наследование если его нет?


На стадии БефоИнхеретанс можно сделат так:
typeBuilder.t_extends = список_PExpr_описывающий_базовый_тип_и_реализуемые_интерфейсы;

Но лучше не задавать базовыйт тип, а задать и реализовать интерфейс. Лучше не связывать пользователя твоей библиотеки такими вещами как нследование реализации. Он может найти лучшее применение этой фиче.

Интерфейс можно добавить с помощью метода TypeBuilder.AddImplementedInterface().
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: бинд типов в макросах
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.04.10 15:12
Оценка: 6 (1)
Здравствуйте, Ziaw, Вы писали:

VD>>>Сори, конечно же TypeBuilder.Ast.t_extends.


VD>>Надо переименовать это дело во что-то приличное. У этих поляков с именами полный дурдом был.


Z>Может он internal? В Ast тоже не видно.


Просто тип свойства Ast — это TopDeclaration, а t_extends есть только у TopDeclaration.Class, TopDeclaration.Interface, TopDeclaration.Variant и TopDeclaration.Enum. Так что код должен быть примерно таким:
match (typeBuilder.Ast)
{
  | Class     as t => t.t_extends = xxx
  | Interface as t => t.t_extends = xxx
  | Variant   as t => t.t_extends = xxx
  | _              => () // для остальных типов ничего не делаем
}
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: DSL на макрах, не потерять автокомплит
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.04.10 16:11
Оценка: 2 (1)
Здравствуйте, Ziaw, Вы писали:

Z>Расскажи, плиз, если это можно рассказать кратко. Как дизайнить чтобы не потерять автокомплит?


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

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

Предположим, что мы хотим получить описание добавления колонки следующего вида:
    addcolumn (Id to someTable)
    {
      PrimaryKey = true;
      Type = ColumnType.Integer();
    }


Для того чтобы можно было получить помлит-ворд для PrimaryKey и Type они должны как-то присутствовать в сгенерированном коде. Например, их можно объявить как локальные переменные.

Вот как может выглядеть реализация такого макроса (она ничего не делает, только выводит полученную информацию на консоль):
public variant ColumnType
{
  | Integer
  | String { len : int }
  | Float
}

namespace MigrationSytaxMacro
{
  public macro AddColumnMacro(name, tableName, body)
  syntax ("addcolumn", "(", name, "to", tableName, ")", body)
  {
    def name      = name.ToString();
    def tableName = tableName.ToString();

    <[ 
        // usesite - позволяет преодалеть гигееничность макросов и использовать цвета имен из контекста применения
        mutable $("PrimaryKey" : usesite) = false; 
        mutable $("Type" : usesite)       = ColumnType.String(-1); // начальные значения определяют тип переменных!
        
        $body; // тело

        // чтобы квази-цитаты не пересикались с $ в $-строках, вводим переменные...
        // их имена гигиеничны (не могут пересечься с аналогичными из пользовательского кода).
        def name        = $(name : string);
        def tableName   = $(tableName : string);
        def primaryKey  = $("PrimaryKey" : usesite);
        def ty          = $("Type" : usesite);
        
        System.Console.WriteLine($"PrimaryKey=$primaryKey Type=$ty name=$(name : string) tableName=$tableName");
     ]>
  }
}
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: DSL на макрах, не потерять автокомплит
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.04.10 17:58
Оценка: 1 (1)
Здравствуйте, Ziaw, Вы писали:

Z>Так и планируется, ColumnType внутренняя деталь реализации. Указывать его конечному пользователю не придется. Но обязательно будет такая возможность, т.к. дотнетовских типов к сожалению недостаточно для точного указания. Тот же string может мапиться на (n)char, (n)nvarchar, (n)text.


Дык и указывай эти детали в виде дополнительного синтаксиса или атрибутов.

В прочем, если это внутренняя реализация и пользователь не будет вынужден указывать эти самые ColumnType, то ОК. Вопрос снят. Просто в твоем коде он присутствовал явно в пользовательском коде.

VD>>Поддерживает поле null или нет тоже можно указывать вописании типов (в нотации нулабл-типов). Например:

VD>>ColName : int?.

Z>Тоже думал, со string такой номер не прокатит.


Это в C# не прокатит. А в немерле, пока код является PExpr-ешеном — прокатит. Главное, чтобы ты успел его разобрать до превращения в тот код который будет реально компилироваться.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
бинд типов в макросах
От: Ziaw Россия  
Дата: 12.04.10 05:12
Оценка:
Есть макрос, который должен нагенерить таких свойств в класс.

        public Persons : BLToolkit.Data.Linq.Table[ Nemerle.MVC.Models.Person ]
        {
            get { this.GetTable.[Nemerle.MVC.Models.Person]();}
        }


      foreach (modelType in modelTypes)
      {
        def typeName = modelType.Name;
        def propertyName = $"$(typeName)s";
        def typeFullName = modelType.FullName;
        def propType = $"BLToolkit.Data.Linq.Table[ $typeFullName ]";
        
        t.Define(<[decl:
            public $(propertyName : dyn) : $(propType : dyn)
            {
              get { this.GetTable.[$(typeFullName : dyn)](); }
            }
        ]>);
      }


При компиляции вылетают "Error: unbound type name 'BLToolkit.Data.Linq.Table[ Nemerle.MVC.Models.Person ]'" причем в двойном экземпляре. Как ему указать на тип? Кстати, когда я делал
        t.Define(<[decl:
            public $(propertyName : dyn) : BLToolkit.Data.Linq.Table[$(typeFullName : dyn)]
            {
              get { this.GetTable.[$(typeFullName : dyn)](); }
            }
        ]>);

unbound был тип Nemerle.MVC.Models.Person.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[2]: бинд типов в макросах
От: Ziaw Россия  
Дата: 12.04.10 11:25
Оценка:
Здравствуйте, hardcase, Вы писали:

Спасибо, помогло Еще вопрос, как создать из строки PExpr.Literal?
def str = "test";
<[ someMethod(str); ]>


И можно ли всетаки определить наследование если его нет?
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[4]: бинд типов в макросах
От: Ziaw Россия  
Дата: 12.04.10 11:42
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


Z>>Спасибо, помогло Еще вопрос, как создать из строки PExpr.Literal?

WH>Во-первых его можно сконструировать напрямую PExpr.Literal(Nemerle.Compiler.Literal.String(str))

Это я пробовал, он еще NemerleLocation хочет.

WH>Во-вторых можно сделать так:

WH>
WH>def str = "test";
WH><[ someMethod($(str : string)); ]>
WH>

Спасибо, как раз сейчас читал статью с примером "<[ def y = $(Bar.Compute() : int) ]>" и сам допер.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[3]: бинд типов в макросах
От: hardcase Пират http://nemerle.org
Дата: 12.04.10 12:08
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>И можно ли всетаки определить наследование если его нет?


Не уверен в ответе, но по-моему это невозможно.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[4]: бинд типов в макросах
От: Ziaw Россия  
Дата: 12.04.10 12:34
Оценка:
Здравствуйте, hardcase, Вы писали:

Z>>И можно ли всетаки определить наследование если его нет?


H>Не уверен в ответе, но по-моему это невозможно.


Жаль А добавить пользовательские аттрибуты классу на который он сам применяется как атрибут?
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[2]: бинд типов в макросах
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.04.10 19:35
Оценка:
Здравствуйте, hardcase, Вы писали:

H>typeFullName видимо имеет тип string. И он превращается в единственный PExpr.Ref, тогда как для правильного "понимания" компилятором имени типа там нужно передавать цепочку PExpr.Member (писал в браузере):

H>
H>def full_name_to_expr(name : string) {
H>    match(NString.Split(name, ".")) {
H>        | [] => <[ () ]>
H>        | n :: [] => <[ $(n : dyn) ]>
H>        | n :: ns => ns.FoldLeft(<[ $(n : dyn) ]>, (n, acc) => <[ $acc.$(n : dyn) ]>)
H>    }
H>}
H>


Если не изменяет склероз, штатная функйия для этого называется PExpr.FromQualifiedIdentifier().
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: бинд типов в макросах
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.04.10 19:46
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Жаль А добавить пользовательские аттрибуты классу на который он сам применяется как атрибут?

typeBuilder.GetModifiers().AddCustomAttribute(PExpr_описывающий_вызов_атрибута)
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: бинд типов в макросах
От: Ziaw Россия  
Дата: 13.04.10 00:46
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Z>>И можно ли всетаки определить наследование если его нет?


VD>На стадии БефоИнхеретанс можно сделат так:

VD>
VD>typeBuilder.t_extends = список_PExpr_описывающий_базовый_тип_и_реализуемые_интерфейсы;
VD>

VD>Но лучше не задавать базовыйт тип, а задать и реализовать интерфейс. Лучше не связывать пользователя твоей библиотеки такими вещами как нследование реализации. Он может найти лучшее применение этой фиче.

Ты уже не первый мне это утверждаешь Поскольку ты первый кто при этом помог, я расскажу зачем это нужно. Я хочу в приложении абстрагироваться от ORM. Есть классы [Model] и [DataBaseManager], в зависимости от подключенной макробиблиотеки модели даются разные атрибуты мапинга а менеджер наследуется от нужного контекста/менеджера. Все что нужно от ORM это поддерживать линк и уметь генерить маппинг по атрибутам. Это linq, EF, BLToolkit, NHibernate. Согласисись неплохой список поддерживаемых ОРМ? Я что-то не помню чтобы пользователи этих либ просили контекст не наследующийся от базового.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[5]: бинд типов в макросах
От: Ziaw Россия  
Дата: 13.04.10 02:38
Оценка:
Здравствуйте, Ziaw, Вы писали:

VD>>На стадии БефоИнхеретанс можно сделат так:

VD>>
VD>>typeBuilder.t_extends = список_PExpr_описывающий_базовый_тип_и_реализуемые_интерфейсы;
VD>>

typeBuilder : Nemerle.Compiler.TypeBuilder ? что-то не нашел я в нем t_extends.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[5]: бинд типов в макросах
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.04.10 12:55
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Ты уже не первый мне это утверждаешь Поскольку ты первый кто при этом помог, я расскажу зачем это нужно. Я хочу в приложении абстрагироваться от ORM. Есть классы [Model] и [DataBaseManager], в зависимости от подключенной макробиблиотеки модели даются разные атрибуты мапинга а менеджер наследуется от нужного контекста/менеджера. Все что нужно от ORM это поддерживать линк и уметь генерить маппинг по атрибутам. Это linq, EF, BLToolkit, NHibernate. Согласисись неплохой список поддерживаемых ОРМ? Я что-то не помню чтобы пользователи этих либ просили контекст не наследующийся от базового.


Думаю что:
1. Хватило бы BLToolkit-а. Распыляя силы на поддержку разных ОРМ-ов ты тратишь драгоценное время.
2. В любом случае наследование не лучший выход. Лучше использовать паттерн Фасад (реализоват его на макросах).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: бинд типов в макросах
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.04.10 12:57
Оценка:
Здравствуйте, Ziaw, Вы писали:

VD>>>На стадии БефоИнхеретанс можно сделат так:

VD>>>
VD>>>typeBuilder.t_extends = список_PExpr_описывающий_базовый_тип_и_реализуемые_интерфейсы;
VD>>>

Z>typeBuilder : Nemerle.Compiler.TypeBuilder ? что-то не нашел я в нем t_extends.

Сори, конечно же TypeBuilder.Ast.t_extends.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: бинд типов в макросах
От: Ziaw Россия  
Дата: 13.04.10 13:08
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>1. Хватило бы BLToolkit-а. Распыляя силы на поддержку разных ОРМ-ов ты тратишь драгоценное время.


Я не поддерживаю их. Я лишь оставляю возможность написать макрос для поддержки. Сейчас Db наследуется от DbManager жестко в коде, если переписать это в макрос, макрос для EF сможет задать свой контекст и больше ничего настраивать не придется.

VD>2. В любом случае наследование не лучший выход. Лучше использовать паттерн Фасад (реализоват его на макросах).


Напиши как ты это видишь. И в какой ситуации может помешать наследование которое хочу сделать я.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[7]: бинд типов в макросах
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.04.10 17:50
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Напиши как ты это видишь. И в какой ситуации может помешать наследование которое хочу сделать я.


Твой класс менеджера описывает общий интерфейс. Нужное содержимое в этому классу докидывается макросами в зависимости от провайдера.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: бинд типов в макросах
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.04.10 19:24
Оценка:
Здравствуйте, VladD2, Вы писали:

Z>>typeBuilder : Nemerle.Compiler.TypeBuilder ? что-то не нашел я в нем t_extends.


VD>Сори, конечно же TypeBuilder.Ast.t_extends.


Надо переименовать это дело во что-то приличное. У этих поляков с именами полный дурдом был.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: бинд типов в макросах
От: Ziaw Россия  
Дата: 14.04.10 02:55
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Z>>Напиши как ты это видишь. И в какой ситуации может помешать наследование которое хочу сделать я.


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


А нужен ли этот общий интерфейс? Я не представляю общего интерфейса для гибернейта и тулкита. Зачем кого-то загонять в общий инетрфейс? Зачем пользователя гибернейта Я даю максимальную свободу и просто возможность не писать то, что и так указано — указано что класс DatabaseManager — подключаем тулкит, он DbManager, подбключаем гибернейт — он SessionFacade. Мне не надо в шаблоне приложения прописывать явное наследование от того или другого. С другой строны, если пользовтель захотел наследовать его от своего (непонятно зачем, но захотел), так его право, пусть наследует от любого класса с реализацией GetTable[T](). Все что я хочу — не впихивать в шаблон приложения выделенное:

[DatabaseManager]
class Db : DbManager {};


DRY, мы уже указали роль класса, если захотим явно указать предка — нет проблем, я не завязываюсь на реализацию. Скорее всего кроме того, что он IDisposable лично нрельсам от него ничего не нужно будет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
DSL на макрах, не потерять автокомплит
От: Ziaw Россия  
Дата: 14.04.10 03:15
Оценка:
Здравствуйте, VladD2, Вы писали:

Расскажи, плиз, если это можно рассказать кратко. Как дизайнить чтобы не потерять автокомплит?

Вот мне надо вызову:

CreateTable("Test", t : TableActions => { // типы указаны для читабельности
  t.Add(c : ColumnActions => {
    c.Name = "Id";
    c.PrimaryKey = true;
    c.Type = ColumnType.Integer;
  })
})


Придать человеческий вид

Для начала можно экстеншенами.
CreateTable("Test", t => {
  t.Integer("Id", new(PrimaryKey = true));
})


А потом уже хочется DSL.
create Test 
{
  Id : Integer, PrimaryKey;
}



Реально получить тут автокомплит на Integer и PrimaryKey? Может что-то можно сделать по другому?

Все что у меня получилось это я даже не могу убрать "t =>"

create Test, t =>
{
  t.Integer("Id", new(PrimaryKey = true));
}



Этого маловато, для оправдания введения нового макроса, имхо.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[8]: бинд типов в макросах
От: Ziaw Россия  
Дата: 14.04.10 06:05
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Z>>>typeBuilder : Nemerle.Compiler.TypeBuilder ? что-то не нашел я в нем t_extends.


VD>>Сори, конечно же TypeBuilder.Ast.t_extends.


VD>Надо переименовать это дело во что-то приличное. У этих поляков с именами полный дурдом был.


Может он internal? В Ast тоже не видно.
Re[9]: бинд типов в макросах
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.04.10 16:23
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>А нужен ли этот общий интерфейс? Я не представляю общего интерфейса для гибернейта и тулкита.


Это тебе решать. Если нужны только разные реализации, то можешь только докидывать разную реализацию методов (приватных) в зависимости от провайдера.

Z>Зачем кого-то загонять в общий инетрфейс? Зачем пользователя гибернейта Я даю максимальную свободу и просто возможность не писать то, что и так указано — указано что класс DatabaseManager — подключаем тулкит, он DbManager, подбключаем гибернейт — он SessionFacade. Мне не надо в шаблоне приложения прописывать явное наследование от того или другого.


Это все к делу не относится. Главное, что наследование тут лишнее. Если тебе нужно можешь использовать макру Aggregation или еще что-то.

Z>С другой строны, если пользовтель захотел наследовать его от своего (непонятно зачем, но захотел),


А это уже его проблема. Если ему понадобится наследование реализации, то оно у него будет.

Z> так его право, пусть наследует от любого класса с реализацией GetTable[T]().


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

Z>Все что я хочу — не впихивать в шаблон приложения выделенное:


Z>
Z>[DatabaseManager]
Z>class Db : DbManager {}; 
Z>


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


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

Z>Скорее всего кроме того, что он IDisposable лично нрельсам от него ничего не нужно будет.


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

Короче, дизайн должен быть рассчитан на простоту использования и расширения. Чем меньше ты создашь ограничений и препонов для конечного пользователя-программиста, тем удобнее ему будет и тем выше он оценит твою реализацию.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: DSL на макрах, не потерять автокомплит
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.04.10 16:54
Оценка:
Здравствуйте, VladD2, Вы писали:

По поводу ColumnType...

Лично мне больше бы понравилось если этого описания не было бы вообще. Есть дотнетные типы. Их более чем достаточно для описания чего угодно. Нужно сделать грамотное отображения некоторого сабсэта дотнетных типов на типы СУБД.

Поддерживает поле null или нет тоже можно указывать вописании типов (в нотации нулабл-типов). Например:
ColName : int?.

В общем, чем короче и проще описание тем лучше.

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

В приведенном мною примере ColumnType описан в макрос-сборке — это очень плохой подход пригодный только для примеров и на скорую руку слепленных прототипов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: DSL на макрах, не потерять автокомплит
От: Ziaw Россия  
Дата: 14.04.10 17:45
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>По поводу ColumnType...


VD>Лично мне больше бы понравилось если этого описания не было бы вообще. Есть дотнетные типы. Их более чем достаточно для описания чего угодно. Нужно сделать грамотное отображения некоторого сабсэта дотнетных типов на типы СУБД.


Так и планируется, ColumnType внутренняя деталь реализации. Указывать его конечному пользователю не придется. Но обязательно будет такая возможность, т.к. дотнетовских типов к сожалению недостаточно для точного указания. Тот же string может мапиться на (n)char, (n)nvarchar, (n)text.

VD>Поддерживает поле null или нет тоже можно указывать вописании типов (в нотации нулабл-типов). Например:

VD>ColName : int?.

Тоже думал, со string такой номер не прокатит.

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

VD>В приведенном мною примере ColumnType описан в макрос-сборке — это очень плохой подход пригодный только для примеров и на скорую руку слепленных прототипов.

Я понял.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.