Создал проект http://code.google.com/p/nemerleonrails/
В связи с этим возник вопрос:

есть классы модели для bltoolkit:

[Model] // макрос, генерирующий свойства и атрибуты маппинга по схеме БД (пока просто из заглушки)
class Doctor
{
}

И класс DbManager

[DbManager] // это гипотетический макрос...
class Db: DbManager
{
    public Doctors : Table[Doctor] //... который должен генерить вот такие свойства для кажого класса модели
    {
        get { this.GetTable.[Doctor]();}
    }
}

Как мне перебрать все классы помеченные макросом Model?

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

Z>Как мне перебрать все классы помеченные макросом Model?

Сделать модуль который обрабатывает логику макроса Model:

[MacroUsage(MacroPhase.BeforeInheritance, MacroTargets.Class)]
macro Model(tb : TypeBuilder) {
   ModelImpl.RegisterType(tb);
}

[MacroUsage(MacroPhase.WithTypedMembers, MacroTargets.Class)]
macro Model(tb : TypeBuilder) {
  // основная логика макроса
}

module ModelImpl {

    types : List[TypeBuilder] = List();

    public RegisterType(tb : TypeBuilder) : void {
        types.Add(tb);
    }

}

На стадии BeforeInheritance запоминаем все типы, помеченные этим макросом, и на следующих стадиях в коллекции types уже будут TypeBuilder-ы.

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

Z>Создал проект http://code.google.com/p/nemerleonrails/

Вопрос не в тему. Ты там пишешь, что райнтайм расширение классов в дотнете не очень доступно. А что мешает? Есть же SRE, IDynamicObject.

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

ВВ>Вопрос не в тему. Ты там пишешь, что райнтайм расширение классов в дотнете не очень доступно. А что мешает? Есть же SRE, IDynamicObject.

Что такое SRE? Не очень — значит я не могу взять и просто добавить методы к имеющемуся классу не изменяя сам класс как в руби. Опять же, тулкит не замапит IDynamicObject, а если заставить его замапить, производительность будет страдать не слабо. Хотя, вероятно, будет все равно быстрее рельс.

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

ВВ>Вопрос не в тему.

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

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

Z>не могу взять и просто добавить методы к имеющемуся классу не изменяя сам класс

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

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

Z>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Вопрос не в тему. Ты там пишешь, что райнтайм расширение классов в дотнете не очень доступно. А что мешает? Есть же SRE, IDynamicObject.
Z>Что такое SRE? Не очень — значит я не могу взять и просто добавить методы к имеющемуся классу не изменяя сам класс как в руби. Опять же, тулкит не замапит IDynamicObject, а если заставить его замапить, производительность будет страдать не слабо. Хотя, вероятно, будет все равно быстрее рельс.

SRE — System.Reflection.Emit. С помощью него можно сэмитировать модель prototype OOP через delegation. Т.е. создается новый объект, он обворачивает ссылку на старый, в него могут добавлять новые свойства. Чтение старых свойств == чтение свойств прототипа. Запись новых == создание нового слота.

Про тулкит не скажу.

По скорости если все написать на голом рефлекшине все равно будет быстрее, чем Руби. Руби весьма не быстр, даже по сравнению с другими скриптами. Однако популярности ROR это не мешает.
По факту если нужна динамика — можно сделать динамику не хуже. Дотнет весьма динамичный рантайм. Надо понять все случаи, когда рулит динамика, насколько их все можно строго-типизировать.

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

Z>Я тоже не в тему задам. Почему нет ни критики ни новых идей в тему? Я куда-то совсем не туда иду, что даже комментировать не хочется? Или мне одному видится перспективным данное направление? Все обсуждение заключается в спорах с Владом что лучше модель по базе или база по модели и еще один человек упорно доказывает, что круче рельс только рельсы и без копирования рельсовского ORM проект обречен.

Идеи штука такая, в мгновение ока не появляются. То, что ты предлагаешь — это улучшенный MVC с тулкитом в качестве ORM. Тут даже непонятно что сказать Если строго со стороны смотреть на все это дело, то я вижу, что предлагается более легкий синтаксис, т.е. все тоже самое, но надо писать меньше букв. Мне кажется этого... мало что ли.

Я бы начал чуть более издалека. Какие задачи должен решать этот фреймворк? Т.е. в чем он будет особенно хорош по сравнению с альтернативами? Он упростит создание веб-приложений, их можно будет делать быстрее? Он позволит разрабатывать более масштабируемые приложения? И т.д. и пр. Таких вопросов много, и убить всех зайцев как правило не получается.

Я бы больше смотрел в стороне первого — т.е. простоты создания. Таких проектов очень много, в т.ч. и в бизнесе. Монструозные приложения же как правило или а) уже написаны или б) пишутся на своих монструозных фреймворках, заточенных под свои конкретные сценарии и задачи.

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

ВВ>SRE — System.Reflection.Emit. С помощью него можно сэмитировать модель prototype OOP через delegation. Т.е. создается новый объект, он обворачивает ссылку на старый, в него могут добавлять новые свойства. Чтение старых свойств == чтение свойств прототипа. Запись новых == создание нового слота.

Мысль понятна, можно еще вспомнить про всякие DynamicProxy, что это даст? Тот же проект, с куда бОльшими трудозатратами и сильно ограниченными возможностями. Я не готов платить такую цену только для того, чтобы продолжать писать на C#. Типизация до рантайма, кстати, идет лесом сразу же. В моем прототипе за пару часов (немерле не знаю вообще) сделана базовая генерация модели, все доступно как будто я руками эти свойства писал, давно так не радовал меня результат программирования . Если бы был провайдер метаданных из базы, с первым этапом было бы уже покончено и можно было переходить к миграциям.

ВВ>По скорости если все написать на голом рефлекшине все равно будет быстрее, чем Руби. Руби весьма не быстр, даже по сравнению с другими скриптами. Однако популярности ROR это не мешает.

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

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

В рельсах

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

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

Если задача просто в том, чтобы воспроизвести РОР со статической типизацией, то сначала надо показать, что все фичи РОР в эту самую статическую типизацию укладываются.

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

ВВ>Я бы начал чуть более издалека. Какие задачи должен решать этот фреймворк? Т.е. в чем он будет особенно хорош по сравнению с альтернативами? Он упростит создание веб-приложений, их можно будет делать быстрее? Он позволит разрабатывать более масштабируемые приложения? И т.д. и пр. Таких вопросов много, и убить всех зайцев как правило не получается.

ВВ>Я бы больше смотрел в стороне первого — т.е. простоты создания. Таких проектов очень много, в т.ч. и в бизнесе. Монструозные приложения же как правило или а) уже написаны или б) пишутся на своих монструозных фреймворках, заточенных под свои конкретные сценарии и задачи.

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

Кстати еще идея возникла, насчет jscript. Так как все экшены и их параметры нам известны — аякс можно превратить в вид:

user.get(userId, function(user) {...});
// или
$("#userPlace").load(user.show(userId));

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

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

ВВ>>Я бы больше смотрел в стороне первого — т.е. простоты создания. Таких проектов очень много, в т.ч. и в бизнесе. Монструозные приложения же как правило или а) уже написаны или б) пишутся на своих монструозных фреймворках, заточенных под свои конкретные сценарии и задачи.
Z>Я туда же смотрю. Простота создания и легкость сопровождения и развития. Кстати тестов на нее писать надо будет куда меньше, большинство типичных ошибок рельсов, изза которых без тестирования на них делать нечего, будут ловиться компилятором. Т.е. добавляем "устойчивость", что ли.

Начни хотя бы с того, чтобы описать идею "словами", а не в стиле берем MVC, берем BLToolkit, заливает сверху макросами и блюдо готово. Я с тулкитом не работал, Влад вот тут писал, что у него поверхностное представление об MVC — неудивительно, что никакой "критики и идей" нет, многое попросту не понимаю, что конкретно предлагается.

Потом тема макросов раскрыта, а "тема сисек", извините, нет. Немерле не только язык с МП, но в отличие от Шарпа да и от Руби это полноценный ФЯ. А ФП как раз очень хорошо ложится на веб, на пользовательские интерфейсы. Ведь тут же стоит классическая задача — трансформация данных.

Z>Кстати еще идея возникла, насчет jscript. Так как все экшены и их параметры нам известны — аякс можно превратить в вид:
Z>

Z>user.get(userId, function(user) {...});
Z>// или
Z>$("#userPlace").load(user.show(userId));
Z>

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

Ага, а еще можно компилятор Немерле в ДжаваСкрипт сделать. Или добавить поддержку JS в виде макроса, но при этом со всеми плюшками ИДЕ. Много чего можно.

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

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

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

Нене, тезис был в том, что практически все, что рельсы генерят динамикой можно узнать до рантайма. Если это можно сделать, зачем это все делать во время работы приложения а в момент разработки только надеяться на то, что у класса User появится свойство name?

ВВ>Если задача просто в том, чтобы воспроизвести РОР со статической типизацией, то сначала надо показать, что все фичи РОР в эту самую статическую типизацию укладываются.

Для этого надо знать на ВСЕ фичи ror. Если учесть, что ror это в первую очередь куча плагинов к ror, то врядли найдется такой человек. Что мешает не копировать весь РОР, а имплементить в каком-то порядке те фичи которые сильно облегчат жизнь в MVC? Тупо копировать ror жизни может не хватить, чтобы их догнать учитывая огромное комьюнити пишущее плагины. И еще, при полной копии и хорошем комьюнити, как только будет выходить новый релиз рельсов — все судорожно начнут хотеть фичи из нового релиза и ругаться, если ты их задержишь.

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

Z>Нене, тезис был в том, что практически все, что рельсы генерят динамикой можно узнать до рантайма. Если это можно сделать, зачем это все делать во время работы приложения а в момент разработки только надеяться на то, что у класса User появится свойство name?

Вот это на мой взгляд плохой подход к дизайну — "практически все, что рельсы...". При этом фичи РОР мы на самом деле не знаем полностью. Исследования не проводилось, просто делаем предположения. На этом и строится весь фреймворк. А я вот постоянно сталкиваюсь с тем, что для веб-приложений наиболее удобной моделью разработки является этакий REP-loop, и очевидные минусы динамики дают и очевидные плюсы — возможность менять состояние среды динамически, в процессе выполнения.

Я не предлагаю это писать на C#, как ты там обмолвился, упаси бог. Мне непонятно, почему использование Немерле и макросов должно означать отказ от любой динамики вообще, положенный в качестве design принципа в основание фреймворка. Когда при этом еще неясно какие фичи вообще будут.

ВВ>>Если задача просто в том, чтобы воспроизвести РОР со статической типизацией, то сначала надо показать, что все фичи РОР в эту самую статическую типизацию укладываются.
Z>Для этого надо знать на ВСЕ фичи ror. Если учесть, что ror это в первую очередь куча плагинов к ror, то врядли найдется такой человек. Что мешает не копировать весь РОР, а имплементить в каком-то порядке те фичи которые сильно облегчат жизнь в MVC? Тупо копировать ror жизни может не хватить, чтобы их догнать учитывая огромное комьюнити пишущее плагины. И еще, при полной копии и хорошем комьюнити, как только будет выходить новый релиз рельсов — все судорожно начнут хотеть фичи из нового релиза и ругаться, если ты их задержишь.

Если задача создать что-то популярное, то да, надо знать ВСЕ фичи ror. Узнать ВСЕ фичи ROR гораздо проще все-таки, чем написать ROR-killer.
А MVC + syntax sugar это, мне кажется, на killer app как-то не тянет.

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

ВВ>Ага, а еще можно компилятор Немерле в ДжаваСкрипт сделать.
Это кстати не так сложно как кажется.
За основу можно взять макрос Late.

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

ВВ>>Ага, а еще можно компилятор Немерле в ДжаваСкрипт сделать.
WH>Это кстати не так сложно как кажется.
WH>За основу можно взять макрос Late.

Late же вроде как сахар для рефлекшина.
Сложно или несложно — не знаю. Но компиляторы C# -> JavaScript есть. Думаю, на Немерле это уж по крайней мере не сложнее. Последнее время мне начинает казаться, что идея возможна не столь уж и плоха.

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

ВВ>Начни хотя бы с того, чтобы описать идею "словами", а не в стиле берем MVC, берем BLToolkit, заливает сверху макросами и блюдо готово. Я с тулкитом не работал, Влад вот тут писал, что у него поверхностное представление об MVC — неудивительно, что никакой "критики и идей" нет, многое попросту не понимаю, что конкретно предлагается.

М... что значит словами? Моя идея описана словами на гуглкоде. Она в том, чтобы избавиться от недостатков MVC которыми не страдает ror. Недостатки расписаны по пунктам. То, что туманных перспектив от немерла просто рой он распирает мою бедную голову, я не могу описать словами.

ВВ>Потом тема макросов раскрыта, а "тема сисек", извините, нет. Немерле не только язык с МП, но в отличие от Шарпа да и от Руби это полноценный ФЯ. А ФП как раз очень хорошо ложится на веб, на пользовательские интерфейсы. Ведь тут же стоит классическая задача — трансформация данных.

Да и макрос Continuation тоже супер. Только, боюсь, если я возьмусь за него сейчас, мы не увидим вообще ничего. Я слабо знаю nemerle и строю планы от своих знаний. Возьми проект в свои руки, а я буду писать плюшки которые я хорошо понимаю.

ВВ>Ага, а еще можно компилятор Немерле в ДжаваСкрипт сделать. Или добавить поддержку JS в виде макроса, но при этом со всеми плюшками ИДЕ. Много чего можно.

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

ВВ>Late же вроде как сахар для рефлекшина.
Ну да. А для этого но код переписывает... Осталось его неределать чтобы он переписывал не в рефлекшен, а в жабаскрипт.

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

ВВ>Вот это на мой взгляд плохой подход к дизайну — "практически все, что рельсы...". При этом фичи РОР мы на самом деле не знаем полностью. Исследования не проводилось, просто делаем предположения. На этом и строится весь фреймворк. А я вот постоянно сталкиваюсь с тем, что для веб-приложений наиболее удобной моделью разработки является этакий REP-loop, и очевидные минусы динамики дают и очевидные плюсы — возможность менять состояние среды динамически, в процессе выполнения.

Идея понятна, а стоит ли делать делать эрланг из немерла?

ВВ>Я не предлагаю это писать на C#, как ты там обмолвился, упаси бог. Мне непонятно, почему использование Немерле и макросов должно означать отказ от любой динамики вообще, положенный в качестве design принципа в основание фреймворка. Когда при этом еще неясно какие фичи вообще будут.

Упаси меня господь придумывать такие принципы. Принцип другой, все что известно до рантайма не надо решать динамикой.

ВВ>Если задача создать что-то популярное, то да, надо знать ВСЕ фичи ror. Узнать ВСЕ фичи ROR гораздо проще все-таки, чем написать ROR-killer.
ВВ>А MVC + syntax sugar это, мне кажется, на killer app как-то не тянет.

Хм... а кто пишет рор киллер? Когда писали ASP.NET MVC планировали рор киллер? А между прочим рор это и есть syntax sugar к ORM и роутингу. Плюс миграции. Его любят именно за DRY, который обеспечивается динамическим сахаром и скриптами генерации.

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

H>На стадии BeforeInheritance запоминаем все типы, помеченные этим макросом, и на следующих стадиях в коллекции types уже будут TypeBuilder-ы.
Сенкс, я и сам так хотел сделать. Волновали только два вопроса, не получится ли так, что заргуженная сборка компилятора будет вызывать один и тот же макрос несколько раз. И можно ли добавлять свойства в последующих фазах.