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

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

Z>>Покажи как на C# 4.0 сделать такое:
Z>>

Z>>        public Index() : ActionResult {
Z>>            using (def db = Db())
Z>>            {
Z>>                ViewData["Message"] = $"NRails env: '$(db.Env)'. We have $(db.Persons.Count()) persons."; 
Z>>                ViewData["Taxonomies"] = db.Doctors.Select(d => d.Taxonomy).ToList();
Z>>            }
Z>>            View()
Z>>        }
Z>>// где
Z>>  [DatabaseManager]
Z>>  class Db: DbManager {}
Z>>  [Model]
Z>>    public class Doctor    {}
Z>>

Z>>Это уже работает у меня.

ВВ>Э, а можно более полный пример? Я тут что-то вообще "лопаты" не вижу.
Это полный пример. Лопату выделил. Класс модели Person только упустил, он один в один как Doctor. Расскажи как это делается на динамиках.

ВВ>>>В РОР по определению никаких статических проверок, и людям это нравится. Вопрос, насколько необходимы именно статические, т.е. на этапе компайл-тайма, проверки в веб-приложении. Ведь здесь грань между компайл-таймом и рантаймом стирается. Возьмем тот же ASPX без код бехаинда. Ведь *семантически* он просто напросто убирает стадию компиляции, она по-прежнему есть, но как бы спрятана от пользователя.
Z>>Если бы всех устраивал рор, asp.net mvc был бы никому не нужной безделицей.

ВВ>Преимущество асп-нета перед РОРом — это собственно .NET. Это на мой взгляд, а на твой? Люди бегут из РОРа потому что их пугает динамика?

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

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

ВВ>>Э, а можно более полный пример? Я тут что-то вообще "лопаты" не вижу.
Z>Это полный пример. Лопату выделил. Класс модели Person только упустил, он один в один как Doctor. Расскажи как это делается на динамиках.

Ну ты расскажи для начала как это у тебя делается. В C# — очень просто. Я захожу, открываю дизайнер, перетаскиваю мышкой таблички Person, Doctor и пр. на диаграмму. После этого у меня все появляется. И без всяких динамиков. И как бы получается, что дизайн-тайм генерация тут не особо хуже макросов.

А с помощью IDynamicObject можно попросту генерировать в рантайме.

Кому оба эти варианта не нравится — можно сделать асп-нет билд-провайдер. Опять-таки сделает то же самое, что и макрос. С тем же уровнем юзабилити.

Не та эта область, где макросы рулят. Вот, к примеру, написать компилятор Си-шарпа в ДжаваСкрипт без макросов будет гораздо сложнее.

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

ВВ>>>Э, а можно более полный пример? Я тут что-то вообще "лопаты" не вижу.
Z>>Это полный пример. Лопату выделил. Класс модели Person только упустил, он один в один как Doctor. Расскажи как это делается на динамиках.

ВВ>Ну ты расскажи для начала как это у тебя делается.
http://code.google.com/p/nemerleonrails/wiki/Progress

ВВ>В C# — очень просто. Я захожу, открываю дизайнер, перетаскиваю мышкой таблички Person, Doctor и пр. на диаграмму. После этого у меня все появляется. И без всяких динамиков. И как бы получается, что дизайн-тайм генерация тут не особо хуже макросов.

Хуже он становится позже, когда у тебя 50 таблиц и после изменения структуры тебе приходится грохать в дизайнере все и тащить заново. Впрочем если тебя это устраивает — не пользуйся макрами, фича опциональная.

ВВ>А с помощью IDynamicObject можно попросту генерировать в рантайме.

Ты уверен, что получится сделать db.Doctors.Select(d => d.Taxonomy).ToList() на динамиках?

ВВ>Кому оба эти варианта не нравится — можно сделать асп-нет билд-провайдер. Опять-таки сделает то же самое, что и макрос. С тем же уровнем юзабилити.

Я ней пойму чем этот билд провайдер поможет при разработке. Ты клонишь в сторону генерации кода типа T4 чтоли? Спасибо, обойдусь.

ВВ>Не та эта область, где макросы рулят. Вот, к примеру, написать компилятор Си-шарпа в ДжаваСкрипт без макросов будет гораздо сложнее.

Ага, а в .NET доказывают, что макры для генерации кода на порядок удобнее шаблонов автогенерации, кому верить?

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

Z>Хуже он становится позже, когда у тебя 50 таблиц и после изменения структуры тебе приходится грохать в дизайнере все и тащить заново. Впрочем если тебя это устраивает — не пользуйся макрами, фича опциональная.

Чет, ты загнул. Ты Linq2Sql использовал? Дизайнер есть дизайнер, мне оно не особо нравится, но людям нравится. И ничего там грохать не надо, вполне нормально все с базой синхронизируется.

ВВ>>А с помощью IDynamicObject можно попросту генерировать в рантайме.
Z>Ты уверен, что получится сделать db.Doctors.Select(d => d.Taxonomy).ToList() на динамиках?

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

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

Билд провайдер — еще один вариант генерить код (не текст) по некоторому ДСЛ-ю. Это то, что есть конкретно в АСП.НЕТ и то, что собирались, но так и не добавили в компилятор Шарпа. Это весьма мощная штука. Билд-провайдер не "текст" генерит, он сборки генерит.
Вообще у меня складывается впечатление, что ты не слышал об этом механизме. Если я не прав — no offense. Если все же не слышал — почитай, это весьма интересная штука, знать о ней дело не лишнее:
http://www.pluralsight-training.net/community/blogs/fritz/archive/2004/09/06/2188.aspx

ВВ>>Не та эта область, где макросы рулят. Вот, к примеру, написать компилятор Си-шарпа в ДжаваСкрипт без макросов будет гораздо сложнее.
Z>Ага, а в .NET доказывают, что макры для генерации кода на порядок удобнее шаблонов автогенерации, кому верить?

Не понял. Я вроде тоже самое сказал.

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

Z>>Ты уверен, что получится сделать db.Doctors.Select(d => d.Taxonomy).ToList() на динамиках?

ВВ>Динамик — это сахар к позднему связыванию. Сам по себе он не дает никаких эксклюзивных возможностей, но ты же можешь такой вызов сделать через позднее связывание? Значит, можешь и через динамик.

Я точно не смогу, экспрешн там не динамик, ему надо вывести тип Doctor -> string, а не из чего. Даже без экспрешена это будет просто набор буковок, как в РоР, так я лучше РоР и заюзаю, для него эти проблемы хоть нормальными IDE решаются.

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

ВВ>Билд провайдер — еще один вариант генерить код (не текст) по некоторому ДСЛ-ю. Это то, что есть конкретно в АСП.НЕТ и то, что собирались, но так и не добавили в компилятор Шарпа. Это весьма мощная штука. Билд-провайдер не "текст" генерит, он сборки генерит.
ВВ>Вообще у меня складывается впечатление, что ты не слышал об этом механизме. Если я не прав — no offense. Если все же не слышал — почитай, это весьма интересная штука, знать о ней дело не лишнее:
ВВ>http://www.pluralsight-training.net/community/blogs/fritz/archive/2004/09/06/2188.aspx

Не слышал, почитал ссылку, так и не понял чем "yes, you have to use the CodeDom" лучше T4.

Z>>Ага, а в .NET доказывают, что макры для генерации кода на порядок удобнее шаблонов автогенерации, кому верить?
ВВ>Не понял. Я вроде тоже самое сказал.

Тогда я не пойму, зачем ты меня уже в который раз отговариваешь от макров в пользу CodeDom и T4?

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

ВВ>>Билд провайдер — еще один вариант генерить код (не текст) по некоторому ДСЛ-ю. Это то, что есть конкретно в АСП.НЕТ и то, что собирались, но так и не добавили в компилятор Шарпа. Это весьма мощная штука. Билд-провайдер не "текст" генерит, он сборки генерит.
ВВ>>Вообще у меня складывается впечатление, что ты не слышал об этом механизме. Если я не прав — no offense. Если все же не слышал — почитай, это весьма интересная штука, знать о ней дело не лишнее:
ВВ>>http://www.pluralsight-training.net/community/blogs/fritz/archive/2004/09/06/2188.aspx
Z>Не слышал, почитал ссылку, так и не понял чем "yes, you have to use the CodeDom" лучше T4.

Это компиляция, а не генерация текста. С полной поддержкой интеллисенса и вполне себе статическим контролем. Твоя модель реализуется через этот механизм с точки зрения пользователя практически также.

Z>>>Ага, а в .NET доказывают, что макры для генерации кода на порядок удобнее шаблонов автогенерации, кому верить?
ВВ>>Не понял. Я вроде тоже самое сказал.
Z>Тогда я не пойму, зачем ты меня уже в который раз отговариваешь от макров в пользу CodeDom и T4?

Про Т4 я вообще ничего не говорил. От макросов я тебя не отговариваю. Я лишь говорю, что здесь Немерле не предоставляет какие-то эксклюзивные возможности. И то, что ты делаешь, делается и без Немерле. А модели сейчас вообще модно с визуальных ДСЛ-ей создавать — DSL Toolkit.

MVC же тоже развивается. Выйдет следующая версия, доведут ее до ума, и все твои улучшения, сделанные для проектов на Немерле, окажутся уже за кадром, ибо будет то же самое для любого языка, причем из коробки.

Я просто говорю, что при таком подходе вся мощь Немерле как-то за кадром остается.

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

ВВ>Это компиляция, а не генерация текста. С полной поддержкой интеллисенса и вполне себе статическим контролем. Твоя модель реализуется через этот механизм с точки зрения пользователя практически также.

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

ВВ>Про Т4 я вообще ничего не говорил. От макросов я тебя не отговариваю. Я лишь говорю, что здесь Немерле не предоставляет какие-то эксклюзивные возможности. И то, что ты делаешь, делается и без Немерле.

Ну конечно, DSL для миграций тоже делается своим парсером, не проблема. View engine тоже делается, надо только аддон к студии, не проблема. Что там еще, t4mvc тоже делает почти все что я задумал в одном из пунктов.

ВВ>А модели сейчас вообще модно с визуальных ДСЛ-ей создавать — DSL Toolkit.

Это перпендикулярно моему проекту. Неважно как будет создаваться модель. Если я создам ее силой мысли, остальные возможности не пострадают.

ВВ>MVC же тоже развивается. Выйдет следующая версия, доведут ее до ума, и все твои улучшения, сделанные для проектов на Немерле, окажутся уже за кадром, ибо будет то же самое для любого языка, причем из коробки.

Значит надо развивать проект так, чтобы MVC не корежить, все улучшения будут доступны.

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

Огласи сразу список мощей немерле которые я не буду использовать.

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

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

VD>>А я считаю, что динамика — это почти всегда зло. Иногда, конечно, необходимо. Но если можно без нее, то нужно без нее.

ВВ>А откуда это утверждение?

Тебе нужен адрес где я живу?

Это мое утверждение. Вывод сделан на базе опыта.

VD>Дотнет хорош не в последнюю очередь благодаря как раз большим чисто динамическим возможностям.

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

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

А я и не призываю к этому. Я призываю к тому, чтобы те проверки которые можно сделать во время компиляции, делались бы именно в это время. Ну, а если динамика обусловлена условиями задачи, то пусть она будет.

ВВ>Вам хочется DRY/DIE и статику, а мне хочется REPL

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

VD>>Динамическая компиляция — 100% лучше чем динамическая типизация.

ВВ>Ну я, честно говоря, с трудом себе представляю динамическую компиляцию для *всего* веб-решения.

А для его частей представляешь?

ВВ>Я хочу, чтобы если уж у нас и был бы MVC, то даже чисто теоретически View мог бы быть только View, и вся работа с данными всегда осуществлялась бы через контроллер, и чтобы это нельзя было сломать, даже если бы захотелось.

Ну, я не уверен, что твой посыл так уж правилен. Но я точно знаю, что он никак не противоречит идее максимизации статической типизации.

ВВ>Я не хочу HTML как текста, хочу ДСЛ, HTML литералы, называй как хочешь.

Я тоже. Не знаю только нужны ли HTML-литералы или хватит XML-литералов.

ВВ>Я не хочу class based OOP для описания бизнес-объектов, хочу ADT.

Вот тут не уверен. Мне кажется, что Линка выше крыше для описания модели хранимой в БД. Возможно можно что-то придумать, чтобы можно было отображать некоторые виды данных не на простые классы, а на АлгТД.

ВВ>Я хочу декларативную валидацию.

Хорошее желание. Я бы даже не отказался от полного ее отсутствия, в смысле чтобы она автоматом генерировалась как-то.

ВВ>Я хочу, чтобы между клиентом и сервером не было такой пропасти, и чтобы одинаковые задачи решались одинаково.

Ну, это слишком абстрактно. Но я тоже за мир во всем мире!

ВВ>Ну и ДжаваСкрипт меня подзадолбал, если честно.

Бывает. Меня сея чаша обошла стороной, к счастью.

Только причем тут динамическая типизация?

VD>>Но зачем навязывать человеку свою идеологию?

ВВ>Ну вообще-то я просто пытался понять *его* идеологию.

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

ВВ>У меня нет противоречий, я просто не придерживаюсь точки зрения типа "Х это плохо 100% случаев". Сформированной концепции у меня нет, только "хотелки".

Ну, вот они и выглядят как сумбур. Причем когда они в декларативном виде, то все еще ничего. А когда к ним примешиваются идеи по реализации... то и появляются эти разговоры про динамику.

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

Опиши конкретные примеры того о чем ты говоришь.

ВВ>Да ради бога, переопределил у тебя кто-нибудь оператор + и стал у тебя компилироваться код, который складывает Foo и Bar. Что значит корректно/некорректно?

Пошла какая-то общая софистика...

ВВ>Зачастую нам на этапе компиляции известно не какие операции можно совершать над типом, а какие контракты этот тип реализует. А свалится ли он при каком-нибудь ConvertToInt32 — известно только в рантайме.

Это ошибочная точка зрения насаждаемая современным ООП. На самом деле код должен быть построен так, чтобы даже если ConvertToInt32 не прошел, то приложение все равно корректно продолжило бы работу. Например, выдав сообщение об ошибке (валидация в твоем понимании).

ВВ>Не та эта область ИМХО, чтобы шашкой махать. У тебя все равно куча вещей, которые вылезут в рантайме только. А динамическая типизация ведь и плюсы свои дает.

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

ВВ>Я верно понимаю суть термина "проверка". Если нужные тебе проверки можно сделать до запуска на исполнение, значит искомая цель достигнута. Разве нет?

А зачем мне проверять вручную то, что может проверить компилятора в автомате?

ВВ>В АСП.НЕТ, к слову, именно такая модель. Компиляции как таковой нет. Если хочешь — можешь запустить валидацию. Не хочешь — сразу открывай в браузере.

Не придумывай. Компиляция динамическая, но она есть.

ВВ>К слову — к этому они пришли после сурового коде-бехаинда в первых версиях, где студия по сути заставляла сначала билдить весь проект в ДЛЛ.

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

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

VD>>С тем, что варианты — хорошее предсавление для многих вещей.

ВВ>В смысле ты с этим не согласен?

Со своими высказываниями? Почти всегда!

ВВ>Зачем тебе вообще MVC?
ВВ>Если сделать все наши хотелки, от него останутся рожки да ножки.

Хз. Я с MVC не знаком.

ВВ>>>Вот только там:
ВВ>>>- нет декларативной валидации
VD>>И сделать нельзя?

ВВ>Как? Надо думать. В ХМЛ-е это by design как бы.

А схемы на что?

ВВ>По идее должен быть "формат" специфицирующий модель.

Ну, дык а разве модель в линке — это не тоже самое?

ВВ>Это могут быть и метаданные самих ADT модели.

Очень абстрактно. Я бы с удовольствие послушал об этой идее по подробнее.

ВВ>А ты Ur/Web смотрел?

Да. Концепт интересный. Но насколько это будет практично я сказать не могу. Как ты понимаешь я это дело не использовал.

ВВ>Модель надо оформить в виде ADT. Вью — это трансформатор. В случае с ХМЛ-ем Вью — это XSLT.

Значит так. Данные у нас в БД. Первый уровень абстракции от БД у нас — это модель Линка — проекция то есть.

Преимущества такого подхода в гибкости выборки данных.

Где и зачем здесь роль АлгТД? И как ты видишь преобразование данных БД (или линка) в АлгТД?

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

ВВ>Кому оба эти варианта не нравится — можно сделать асп-нет билд-провайдер. Опять-таки сделает то же самое, что и макрос. С тем же уровнем юзабилити.

Ну, дык и что, что того же эффекта можно добиться если вместо одного программиста с немерлом посадить бригаду с шарпом?

Да можно генерировать код и без макросов. Да то что можно добиться генерацией кода можно добиться и на динамическом метапрограммировании. Тут никто не спорит. Впрос только в быстродействии и объеме кода который нужно написать.

ВВ>Не та эта область, где макросы рулят. Вот, к примеру, написать компилятор Си-шарпа в ДжаваСкрипт без макросов будет гораздо сложнее.

Это не не та, а не только так. То что ты хочешь тоже здорово. Но не только это здорово.

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

VD>А я и не призываю к этому. Я призываю к тому, чтобы те проверки которые можно сделать во время компиляции, делались бы именно в это время. Ну, а если динамика
обусловлена условиями задачи, то пусть она будет.

Тогда и основы для спора нет

ВВ>>Вам хочется DRY/DIE и статику, а мне хочется REPL

ВВ>>Ну я, честно говоря, с трудом себе представляю динамическую компиляцию для *всего* веб-решения.
VD>А для его частей представляешь?

Для частей представляю. Но чтобы у меня дата-лаер компилировался динамически... Причем еще сам, если я базу поменял...

ВВ>>Я не хочу class based OOP для описания бизнес-объектов, хочу ADT.
VD>Вот тут не уверен. Мне кажется, что Линка выше крыше для описания модели хранимой в БД. Возможно можно что-то придумать, чтобы можно было отображать некоторые виды данных не на простые классы, а на АлгТД.

Если не будет ADT, как потом анализировать данные? Циклы писать? Или на ОО-манер городить тонны кода? От этого как раз хочется уйти.

ВВ>>Я хочу декларативную валидацию.
VD>Хорошее желание. Я бы даже не отказался от полного ее отсутствия, в смысле чтобы она автоматом генерировалась как-то.

Для этого каждому вью должен четко соответствовать некий контракт. Им по сути могут выступать и метаданные. Однако одних "голых" метаданных мало, т.е. реальные задачи — это указывать диапазон значений и пр. В ХМЛ-е все это как бы уже есть в виде схемы, возможности схемы все это покрывают. Тут видимо придется вводить какие-нибудь дополнительные атрибуты.

ВВ>>Я хочу, чтобы между клиентом и сервером не было такой пропасти, и чтобы одинаковые задачи решались одинаково.
VD>Ну, это слишком абстрактно. Но я тоже за мир во всем мире!

Ну вот неабстрактное решение есть в Ur/Web. Ur компилируется в ДжаваСкрипт, причем компилятор сам решает, где должен выполняться метод. Если в нем нет обращений к ресурсам на клиенте, то он будет выполняться на сервере. Если есть, то на клиенте. Если и то, и другое — то на клиенте, а обращение к методам на сервере будет автоматически раскрываться в RPC-вызов.

ВВ>>Ну и ДжаваСкрипт меня подзадолбал, если честно.
VD>Бывает. Меня сея чаша обошла стороной, к счастью.
VD>Только причем тут динамическая типизация?

Собственно, я уже и забыл причем она и тут.

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

Весь жизненный этап веб-приложения от "пользователь ввел адрес" до "пользователь увидел страницу" можно описать как цепочку трансформаций: получаем данные в формате Х, преобразуем их в формат У и так далее. Базовые средства АСП.НЕТ никак эту задачу не упрощают, АСП.НЕТ вообще начался с того, что мы решили прикидываться, как будто у нас приложение на десктопе крутится. Лучше всего для этих вещей подходит XSLT, но у него тоже есть очевидные проблемы.

VD>Это ошибочная точка зрения насаждаемая современным ООП. На самом деле код должен быть построен так, чтобы даже если ConvertToInt32 не прошел, то приложение все равно корректно продолжило бы работу. Например, выдав сообщение об ошибке (валидация в твоем понимании).

Во, правильно. Прямо как в динамических языках. Не прошло, проверил, выдал сообщение об ошибке
Блин, опять я...

ВВ>>Не та эта область ИМХО, чтобы шашкой махать. У тебя все равно куча вещей, которые вылезут в рантайме только. А динамическая типизация ведь и плюсы свои дает.
VD>Не у меня, а у нас. И это очень плохо. Чем меньше будет возможности получить ошибок в рантайме, тем надежнее будет программа. Идеал конечно не достижим, но стремиться к нему надо.

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

ВВ>>Я верно понимаю суть термина "проверка". Если нужные тебе проверки можно сделать до запуска на исполнение, значит искомая цель достигнута. Разве нет?
VD>А зачем мне проверять вручную то, что может проверить компилятора в автомате?

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

ВВ>>В АСП.НЕТ, к слову, именно такая модель. Компиляции как таковой нет. Если хочешь — можешь запустить валидацию. Не хочешь — сразу открывай в браузере.
VD>Не придумывай. Компиляция динамическая, но она есть.

Я говорю, что нет выделенной *стадии* компиляции. В питоне вот, к примеру, компиляция тоже есть, но семантически нет такой стадии — написал код в файле, запустил, получил результат.

ВВ>>К слову — к этому они пришли после сурового коде-бехаинда в первых версиях, где студия по сути заставляла сначала билдить весь проект в ДЛЛ.
VD>К слову, до сих пор считаю, что код-бихаинд очень правильный подход. Правда не потомоу, что он более статически типизирован, а потому, что он отделяет представление от логики и позволяет дизайнеру заняться дизайном, а программисту функционалом. (да, знаю о том, что не все там чисто и пушисто, но это опять же идеал...).

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

Потом я неправильно высказался, под коде-бехаиндом я имел в виду то время, когда студия насильно компилировала все в ДЛЛ, хотя АСП.НЕТ с самого начала поддерживал как коде-инсайт, так и коде-бехаинд без всякой предкомпиляции — просто положил рядом файлик с кодом и все.

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


ВВ>>Как? Надо думать. В ХМЛ-е это by design как бы.
VD>А схемы на что?

Какие схемы? Ты про XSD? Ну я их и имел в виду. Или ты хочешь их же и использовать?

ВВ>>По идее должен быть "формат" специфицирующий модель.
VD>Ну, дык а разве модель в линке — это не тоже самое?

Модели будет мало.

ВВ>>Это могут быть и метаданные самих ADT модели.
VD>Очень абстрактно. Я бы с удовольствие послушал об этой идее по подробнее.

В теории все просто — вводятся специальные макросы или атрибуты (и удобный механизм работы с ними), которые позволяют вешать своего рода констрейнты на отдельные поля. Плюс возможность создания собственных констрейнтов. Констрейнт сам по себе описывается в виде этакого воркфлоу и может быть откомпилирован как в Немерле, так в ДжаваСкрипт. Типа:

| Person([CtrRange(1, 20)] age : int)

ВВ>>Модель надо оформить в виде ADT. Вью — это трансформатор. В случае с ХМЛ-ем Вью — это XSLT.
VD>Значит так. Данные у нас в БД. Первый уровень абстракции от БД у нас — это модель Линка — проекция то есть.
VD>Преимущества такого подхода в гибкости выборки данных.
VD>Где и зачем здесь роль АлгТД?

Зачем — для анализа через матчи.

VD>И как ты видишь преобразование данных БД (или линка) в АлгТД?

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

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

ВВ>Для частей представляю. Но чтобы у меня дата-лаер компилировался динамически... Причем еще сам, если я базу поменял...

А зачем это надо?

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

VD>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Для частей представляю. Но чтобы у меня дата-лаер компилировался динамически... Причем еще сам, если я базу поменял...
VD>А зачем это надо?

Опять же — REPL. Надо при разработке, особенно в R&D стиле, тестировании, поиске хитрожопых багов. Ну обычные преимущества репла.
При статике это конечно не имеет смысла.

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

ВВ>Какие схемы? Ты про XSD? Ну я их и имел в виду.

Ага.

ВВ>Или ты хочешь их же и использовать?

Ну, напрямую — нет. Я их плохо знаю и они страшные. Но по сути — да.

ВВ>>>По идее должен быть "формат" специфицирующий модель.
VD>>Ну, дык а разве модель в линке — это не тоже самое?

ВВ>Модели будет мало.

Это ты просто модель очень ограниченно понимаешь.

ВВ>В теории все просто — вводятся специальные макросы или атрибуты (и удобный механизм работы с ними), которые позволяют вешать своего рода констрейнты на отдельные поля. Плюс возможность создания собственных констрейнтов. Констрейнт сам по себе описывается в виде этакого воркфлоу и может быть откомпилирован как в Немерле, так в ДжаваСкрипт. Типа:

ВВ>| Person([CtrRange(1, 20)] age : int)

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

ВВ>>>Модель надо оформить в виде ADT. Вью — это трансформатор. В случае с ХМЛ-ем Вью — это XSLT.
VD>>Значит так. Данные у нас в БД. Первый уровень абстракции от БД у нас — это модель Линка — проекция то есть.
VD>>Преимущества такого подхода в гибкости выборки данных.
VD>>Где и зачем здесь роль АлгТД?

ВВ>Зачем — для анализа через матчи.

Самоцель?


VD>>И как ты видишь преобразование данных БД (или линка) в АлгТД?

ВВ>По большому счету ADT тут ничем не отличается (ну почти) не отличается от обычных классов. Их точно также можно генерить. Например, вся база может быть представлена в виде единого ADT.

Что-то я не вижу в этом смысла. Ну, может просто спать пора.

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


ВВ>Опять же — REPL. Надо при разработке, особенно в R&D стиле, тестировании, поиске хитрожопых багов. Ну обычные преимущества репла.
ВВ>При статике это конечно не имеет смысла.

Я точно так же по F5 отлично все это делаю. И в место репла я предпочел бы наличие динамического зименения кода в рантайме (как это сейчас для шарпа делается).

А вот менять что-то без интеллисенса — это не здорово (для меня).

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

ВВ>>| Person([CtrRange(1, 20)] age : int)
VD>Вот это и есть описание модели. Только совершенно не обязательно варианты сюда приплетать и воркфлоу разные. Просто размечаем атрибутами или синтаксисом описание модели и получаем модель в которой информации достаточно для генерации всего кода проверок. Ну, если проверки уж очень сложные, то добавляем возможность описать их императивно на событиях.

Проверки как правило таки требуют какого-то кода. И возникает вопрос — где должен исполняться это код? На сервере, на клиенте? На каком языке он будет? Поэтому тут скорее нужны цитаты, а не код напрямую.

ВВ>>Зачем — для анализа через матчи.
VD>Самоцель?

Цель — писать меньше кода чем сейчас. По крайней мере одна из.
А что я буду делать с вашими классами? Сейчас я получил классы и запихиваю их в XSLT.

VD>>>И как ты видишь преобразование данных БД (или линка) в АлгТД?
ВВ>>По большому счету ADT тут ничем не отличается (ну почти) не отличается от обычных классов. Их точно также можно генерить. Например, вся база может быть представлена в виде единого ADT.
VD>Что-то я не вижу в этом смысла. Ну, может просто спать пора.

А какой смысл ты видишь в генерации ОО-подобной модели по базе?

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

ВВ>А какой смысл ты видишь в генерации ОО-подобной модели по базе?

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

Варинаты — это полиморфизм. Если у нас будут полиморфные таблицы, то варианты можно будет отобразить на них. А так, я не вижу внятного объяснения применения вариантов.

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

VD>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>А какой смысл ты видишь в генерации ОО-подобной модели по базе?
VD>Не ОО, а скорее кортеже-подобной. Полноценного ООП там не будет. Это всего лишь описание сущностей и отношений между ними средствами языка на котором эти данные будут обрабатываться.

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

VD>Варинаты — это полиморфизм. Если у нас будут полиморфные таблицы, то варианты можно будет отобразить на них. А так, я не вижу внятного объяснения применения вариантов.

Что такое "полиморфные таблицы" мне непонятно. На уровне классической реляционной БД никакого полиморфизма нет. Полиморфизм это то, что появляется в мозгах у программиста, когда он делает отображение базы на "что-то еще". Если "что-то еще" это анемичная модель, то полиморфизма как не было, так и не будет. А если это, скажем, ХМЛ, то полиморфны будут *все* структуры (но при этом по-прежнему статически типизированы).

Схемы же ковырял ХМЛ-ные? На мой взгляд в чем-то похожи на ADT. По крайней мере я могу отобразить свою типичную схему на ADT, и тогда роль XSLT будет выполнять обычный код на Немерле.

Если вы что-то кардинально иное предлагаете, то я хочу понять что. Я пока не понял. Если речь о шаблонах на манер ASP, то их не спасет даже лаконичность и строго-типизированность Немерле, ибо просто убоги. Если какой-то альтернативный механизм — то как он будет выглядеть и работать?

Моя мысль бьется, так сказать, в одном направлении — аналог XML/XSD/XSLT, но без XML.

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

ВВ>Если вы что-то кардинально иное предлагаете, то я хочу понять что. Я пока не понял. Если речь о шаблонах на манер ASP, то их не спасет даже лаконичность и строго-типизированность Немерле, ибо просто убоги. Если какой-то альтернативный механизм — то как он будет выглядеть и работать?

Убогость надо обосновать. Покажи задачу и ее решение на xslt который будет выглядеть убого при переложении на шаблоны.