При компиляции вылетают "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)](); }
}
]>);
Здравствуйте, Ziaw, Вы писали:
Z>При компиляции вылетают "Error: unbound type name 'BLToolkit.Data.Linq.Table[ Nemerle.MVC.Models.Person ]'" причем в двойном экземпляре. Как ему указать на тип? Кстати, когда я делал Z>
typeFullName видимо имеет тип string. И он превращается в единственный PExpr.Ref, тогда как для правильного "понимания" компилятором имени типа там нужно передавать цепочку PExpr.Member (писал в браузере):
Здравствуйте, Ziaw, Вы писали:
Z>Спасибо, помогло Еще вопрос, как создать из строки PExpr.Literal?
Во-первых его можно сконструировать напрямую PExpr.Literal(Nemerle.Compiler.Literal.String(str))
Во-вторых можно сделать так:
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Ziaw, Вы писали:
Z>>Спасибо, помогло Еще вопрос, как создать из строки PExpr.Literal? WH>Во-первых его можно сконструировать напрямую PExpr.Literal(Nemerle.Compiler.Literal.String(str))
Это я пробовал, он еще NemerleLocation хочет.
WH>Во-вторых можно сделать так: WH>
Здравствуйте, hardcase, Вы писали:
H>typeFullName видимо имеет тип string. И он превращается в единственный PExpr.Ref, тогда как для правильного "понимания" компилятором имени типа там нужно передавать цепочку PExpr.Member (писал в браузере): H>
Но лучше не задавать базовыйт тип, а задать и реализовать интерфейс. Лучше не связывать пользователя твоей библиотеки такими вещами как нследование реализации. Он может найти лучшее применение этой фиче.
Интерфейс можно добавить с помощью метода TypeBuilder.AddImplementedInterface().
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Ziaw, Вы писали:
Z>>И можно ли всетаки определить наследование если его нет?
VD>На стадии БефоИнхеретанс можно сделат так: VD>
VD>Но лучше не задавать базовыйт тип, а задать и реализовать интерфейс. Лучше не связывать пользователя твоей библиотеки такими вещами как нследование реализации. Он может найти лучшее применение этой фиче.
Ты уже не первый мне это утверждаешь Поскольку ты первый кто при этом помог, я расскажу зачем это нужно. Я хочу в приложении абстрагироваться от ORM. Есть классы [Model] и [DataBaseManager], в зависимости от подключенной макробиблиотеки модели даются разные атрибуты мапинга а менеджер наследуется от нужного контекста/менеджера. Все что нужно от ORM это поддерживать линк и уметь генерить маппинг по атрибутам. Это linq, EF, BLToolkit, NHibernate. Согласисись неплохой список поддерживаемых ОРМ? Я что-то не помню чтобы пользователи этих либ просили контекст не наследующийся от базового.
Здравствуйте, Ziaw, Вы писали:
Z>Ты уже не первый мне это утверждаешь Поскольку ты первый кто при этом помог, я расскажу зачем это нужно. Я хочу в приложении абстрагироваться от ORM. Есть классы [Model] и [DataBaseManager], в зависимости от подключенной макробиблиотеки модели даются разные атрибуты мапинга а менеджер наследуется от нужного контекста/менеджера. Все что нужно от ORM это поддерживать линк и уметь генерить маппинг по атрибутам. Это linq, EF, BLToolkit, NHibernate. Согласисись неплохой список поддерживаемых ОРМ? Я что-то не помню чтобы пользователи этих либ просили контекст не наследующийся от базового.
Думаю что:
1. Хватило бы BLToolkit-а. Распыляя силы на поддержку разных ОРМ-ов ты тратишь драгоценное время.
2. В любом случае наследование не лучший выход. Лучше использовать паттерн Фасад (реализоват его на макросах).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>1. Хватило бы BLToolkit-а. Распыляя силы на поддержку разных ОРМ-ов ты тратишь драгоценное время.
Я не поддерживаю их. Я лишь оставляю возможность написать макрос для поддержки. Сейчас Db наследуется от DbManager жестко в коде, если переписать это в макрос, макрос для EF сможет задать свой контекст и больше ничего настраивать не придется.
VD>2. В любом случае наследование не лучший выход. Лучше использовать паттерн Фасад (реализоват его на макросах).
Напиши как ты это видишь. И в какой ситуации может помешать наследование которое хочу сделать я.
Здравствуйте, VladD2, Вы писали:
Z>>typeBuilder : Nemerle.Compiler.TypeBuilder ? что-то не нашел я в нем t_extends.
VD>Сори, конечно же TypeBuilder.Ast.t_extends.
Надо переименовать это дело во что-то приличное. У этих поляков с именами полный дурдом был.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Ziaw, Вы писали:
Z>>Напиши как ты это видишь. И в какой ситуации может помешать наследование которое хочу сделать я.
VD>Твой класс менеджера описывает общий интерфейс. Нужное содержимое в этому классу докидывается макросами в зависимости от провайдера.
А нужен ли этот общий интерфейс? Я не представляю общего интерфейса для гибернейта и тулкита. Зачем кого-то загонять в общий инетрфейс? Зачем пользователя гибернейта Я даю максимальную свободу и просто возможность не писать то, что и так указано — указано что класс DatabaseManager — подключаем тулкит, он DbManager, подбключаем гибернейт — он SessionFacade. Мне не надо в шаблоне приложения прописывать явное наследование от того или другого. С другой строны, если пользовтель захотел наследовать его от своего (непонятно зачем, но захотел), так его право, пусть наследует от любого класса с реализацией GetTable[T](). Все что я хочу — не впихивать в шаблон приложения выделенное:
[DatabaseManager]
class Db : DbManager {};
DRY, мы уже указали роль класса, если захотим явно указать предка — нет проблем, я не завязываюсь на реализацию. Скорее всего кроме того, что он IDisposable лично нрельсам от него ничего не нужно будет.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, VladD2, Вы писали:
Z>>>typeBuilder : Nemerle.Compiler.TypeBuilder ? что-то не нашел я в нем t_extends.
VD>>Сори, конечно же TypeBuilder.Ast.t_extends.
VD>Надо переименовать это дело во что-то приличное. У этих поляков с именами полный дурдом был.