Здравствуйте, Воронков Василий, Вы писали:
ВВ>Отделение презентации и логики — это хорошо. Но есть и другие паттерны. Есть хотя бы просто другие подходы к тому же MVC, не обязательно такие как в Рельсах. Взять хотя бы AIDA/Web.
Гляну.
Z>>Ребят, поймите, у меня возникла идея, понравилась, я ее решил реализовать. А вы мне говорите — тебе не то понравилось, давай тебе понравятся прототипы ФЯ.
ВВ>То, что ты хочешь сделать... В общем для этого и Немерле-то не нужен. Достаточно C# с динамиком да билд провайдеров асп-нета, которые в данном случае будут не сильно хуже макросов. И все, блюдо готово.
Странно реализовавать динамикой то, что призвано добавить статики и проверок компиляции. Ты роадмап читал? Что из него можно реализовать динамикой кроме миграций которые не требуют спец возможностей, но DSL для них на немерле приятнее будет.
ВВ>Писать на юр-веб никто не предлагает. Изучить, взять идеи — да. Конечно, это не РОР, за которым стоит бабло Эпла, и нет красивых туториалов с картинками в стиле "создай веб-приложение за 5 минут". Для Немерле их тоже нет. И у многих, кто заходит на nemerle.org точно такая же в общем-то реакция. Это не значит, что вещь плохая. ВВ>И от чего там начинает "тошнить"? Не от HTML литералов же? Если есть какие-то конкретные претензии их и надо обсуждать, т.к. это те области, которые можно сделать лучше.
Ты создай и покажи. Я не хочу равняться на язык на котором простой сайт сделать проблема. Псевдозамыкания я и так планировал сделать. Возможно в будущем посмотрю на него еще, когда для jscripta буду что-то писать.
Здравствуйте, Ziaw, Вы писали:
ВВ>>То, что ты хочешь сделать... В общем для этого и Немерле-то не нужен. Достаточно C# с динамиком да билд провайдеров асп-нета, которые в данном случае будут не сильно хуже макросов. И все, блюдо готово.
Z>Странно реализовавать динамикой то, что призвано добавить статики и проверок компиляции. Ты роадмап читал? Что из него можно реализовать динамикой кроме миграций которые не требуют спец возможностей, но DSL для них на немерле приятнее будет.
Я так вижу тут у тебя две задачи: сократить количество ручного кодирования и добавить статические проверки. Первое можно и на C# 4.0, второе — штука неоднозначная. В РОР по определению никаких статических проверок, и людям это нравится. Вопрос, насколько необходимы именно статические, т.е. на этапе компайл-тайма, проверки в веб-приложении. Ведь здесь грань между компайл-таймом и рантаймом стирается. Возьмем тот же ASPX без код бехаинда. Ведь *семантически* он просто напросто убирает стадию компиляции, она по-прежнему есть, но как бы спрятана от пользователя.
В итоге те статические проверки, которые ты добавишь, могут мало чем отличаться от динамических. Важнее, чтобы они в принципе были. И в Руби они есть (а вот в JS, кстати, отсутствуют).
ВВ>Я так вижу тут у тебя две задачи: сократить количество ручного кодирования и добавить статические проверки. Первое можно и на C# 4.0, второе — штука неоднозначная.
Покажи как на C# 4.0 сделать такое:
public Index() : ActionResult {
using (def db = Db())
{
ViewData["Message"] = $"NRails env: '$(db.Env)'. We have $(db.Persons.Count()) persons.";
ViewData["Taxonomies"] = db.Doctors.Select(d => d.Taxonomy).ToList();
}
View()
}
// где
[DatabaseManager]
class Db: DbManager {}
[Model]
public class Doctor {}
Это уже работает у меня.
ВВ>В РОР по определению никаких статических проверок, и людям это нравится. Вопрос, насколько необходимы именно статические, т.е. на этапе компайл-тайма, проверки в веб-приложении. Ведь здесь грань между компайл-таймом и рантаймом стирается. Возьмем тот же ASPX без код бехаинда. Ведь *семантически* он просто напросто убирает стадию компиляции, она по-прежнему есть, но как бы спрятана от пользователя.
Если бы всех устраивал рор, asp.net mvc был бы никому не нужной безделицей.
Здравствуйте, Ziaw, Вы писали:
Z>Первичной аудиторией я вижу в первую очередь MVC аудиторию. Всем другим придется изучать язык, фреймворк, линк. Слишком круто для массового перехода. А mvc приложение должно работать как обычно, а все фичи используются по желанию.
Язык большинству придется так или иначе изучать. Причем стандартному такому MVC-нику придется изучать не просто язык, а новую парадигму. В ветке "почему я не использую Немерле" ты ведь участвовал, там прекрасно видно, как некоторые товарищи этому сопротивляются. Не все, конечно, ведут себя как базарные бабы, но тенденция такая бесспорно есть.
Так что, повторюсь, это непростой вопрос на самом-то деле. Что легче — продать чистую функциональщину в вебе дотнетчикам или дотнет функциональщикам?
Кстати, наличие большого кол-ва библиотек обычно как раз наоборот является плюсом при переходе на какую-либо платформу.
Z>Рельсы любят именно за то, что они делают своей динамикой.
И вот это весьма важный момент.
Z>А рубистам можно дать быстродействие. Поверь, никого полностью не устраивает скорость рельс.
Я уже говорил — Руби сам по себе очень медленный. А Рельсы явно еще добавляют свой "слой тормозов". Причем Руби медленный не по сравнению с C# или Немерле, а по сравнению с Питоном, ДжаваСкриптом и пр.
Однако же РОР-ом пользуются, пусть никого "полностью не устраивает скорость рельс". Самый факт, что РОР популярен уже говорит, что быстродействие — это не то, что стоит рассматривать именно сейчас как важную фичу. Быстродействие будет лучше. By design. Если окажется, что "недостаточно лучше", то можно будет заняться оптимизацией.
Z>Тулкит это линк. Насчет неповоротливых классов — один из краеугольных камней фреймворка это передача данных во view, я очень надеюсь передавать туда анонимные типы, оставляя их статически типизированными. Но не стал заявлять, пока не изучу немерл получше.
А что потом делать с этими анонимными типами? Нужны алгебраические типы.
ВВ>>В общем мне кажется тут сначала стоит просто посидеть и подумать, а не загонять себя с первого шага в какие-то рамки. Тогда может и правда киллер получится. Z>Кто-то запретил думать? Или ты думаешь, что будет уже столько кода, что его не захочется переписывать? Я вот не могу просто думать, мне проще прототипы нактидывать.
Здравствуйте, 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>Это уже работает у меня.
Э, а можно более полный пример? Я тут что-то вообще "лопаты" не вижу.
ВВ>>В РОР по определению никаких статических проверок, и людям это нравится. Вопрос, насколько необходимы именно статические, т.е. на этапе компайл-тайма, проверки в веб-приложении. Ведь здесь грань между компайл-таймом и рантаймом стирается. Возьмем тот же ASPX без код бехаинда. Ведь *семантически* он просто напросто убирает стадию компиляции, она по-прежнему есть, но как бы спрятана от пользователя. Z>Если бы всех устраивал рор, asp.net mvc был бы никому не нужной безделицей.
Преимущество асп-нета перед РОРом — это собственно .NET. Это на мой взгляд, а на твой? Люди бегут из РОРа потому что их пугает динамика?
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>1) эскейпим по разному, в зависимости от того, куда попала наша строка (см., например, microsoft anti-xss library на codeplex)
H>А не имеет ли смыл идея сделать специальный тип для эскейпнутых строк? Т.е. эскейпинг строки становится просто операцией приведения типа String в EscapeString. Там где нужен эскейпинг методы будут принимать второй тип, а там где он не обязателен — стандартный string.
Имеет. Но типов эскейпнутых строк должно столько, сколько существует различных мест, куда может попасть такая строка (заголовки HTTP, снаружи атрибута HTML, внутри атрибута HTML, в Javascript, CSS и т.п.), т.к. эскпейпить там нужно различными способами.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>То, что ты хочешь сделать... В общем для этого и Немерле-то не нужен. Достаточно C# с динамиком да билд провайдеров асп-нета, которые в данном случае будут не сильно хуже макросов. И все, блюдо готово.
Супер! Тогда закругяемся. Только не забудь отписать ребятам из МС которые пишут MVC, что они олухи и не додумались до таких простых решений .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Я так вижу тут у тебя две задачи: сократить количество ручного кодирования и добавить статические проверки. Первое можно и на C# 4.0, второе — штука неоднозначная.
Слушай, я вот уже долго наблюдаю за тобой в этой теме и не могу понть чего ты добиваешся.
Считаешь что динамика круче. Пойди реализуй то что ты хочешь на C# 4.0. Благо он сегодня уже вышел в свет.
ВВ>В РОР по определению никаких статических проверок, и людям это нравится.
Ну, тем кто нравится будут продолжать жувать кактус динамики на рельсах (рубевых). Если создашь шарповые рельсы (динамические), то могут пожувать и на них (хотя я сильном сомневаюсь, что ты их создашь).
ВВ> Вопрос, насколько необходимы именно статические, т.е. на этапе компайл-тайма, проверки в веб-приложении.
Создай тему в философии — обсуди эту тему, если она тебе интересна. Мне вот она не интересна. У меня даже сомнений нет, что статика всегда лучше динамики, так как чем раньше будет выявлена ошибка тем лучше. Главное, чтобы статика не делала софт менее функциональным и удобным.
Как я понял цель проекта как раз получить статическую типизацию при сохранении простоты и удобства разработки сайтов присущих РОР-у.
ВВ>В итоге те статические проверки, которые ты добавишь, могут мало чем отличаться от динамических. Важнее, чтобы они в принципе были. И в Руби они есть (а вот в JS, кстати, отсутствуют).
Это форменная чушь просто потому, что компиляцию всегда можно запустить до рантайма, а вот рантайм-проверки никода нельзя сделать во время компиляции.
В общем, дай человеку хоть что-то сделать. Не топи порыв энтузиазма в гнилой философии!
Пойми, я тоже обожаю по-филосовствовать. Но нужно где-то остановиться. В какой-то момент философия теряет смысл и становится бессмысленным давлением на моги окружающих.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
Z>>Тулкит это линк. Насчет неповоротливых классов — один из краеугольных камней фреймворка это передача данных во view, я очень надеюсь передавать туда анонимные типы, оставляя их статически типизированными. Но не стал заявлять, пока не изучу немерл получше.
ВВ>А что потом делать с этими анонимными типами? Нужны алгебраические типы.
Вот здесь — согласен!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
Z>я очень надеюсь передавать туда анонимные типы, оставляя их статически типизированными
Максимум что можно делать с анонимными типами (те, что изготавливаются в теле методов) — это представить их в виде иммутабельной key-value коллекции, что собственно и было сделано: немерловый анонимный тип (аналогичный C#) реализует интерфейс Nemerle.Extensions.IAnonymous, это ничем не лучше ViewData.
Кто-нибудь покажет как можно алгебраические типы использовать для передачи "модели" в "представление")?
Здравствуйте, VladD2, Вы писали:
ВВ>>Я так вижу тут у тебя две задачи: сократить количество ручного кодирования и добавить статические проверки. Первое можно и на C# 4.0, второе — штука неоднозначная. VD>Слушай, я вот уже долго наблюдаю за тобой в этой теме и не могу понть чего ты добиваешся. VD>Считаешь что динамика круче.
Я не считаю, что "динамика круче". Я вообще не оперирую такими понятиями как "круче" или "некруче".
У динамики есть свои преимущества. Строить проект на том, что динамика — это баг, который нужно исправить, как-то не совсем правильно. Возможно, есть неполное представление о том, что дает динамическая типизация.
VD>Пойди реализуй то что ты хочешь на C# 4.0. Благо он сегодня уже вышел в свет.
Если ты "долго наблюдаешь за мной", то наверное должен был бы заметить, что "это" совсем не то, что я хочу.
ВВ>>В РОР по определению никаких статических проверок, и людям это нравится. VD>Ну, тем кто нравится будут продолжать жувать кактус динамики на рельсах (рубевых). Если создашь шарповые рельсы (динамические), то могут пожувать и на них (хотя я сильном сомневаюсь, что ты их создашь).
И казалось бы зачем мне шарповые рельсы? Мне вообще не нравится ASP.NET MVC, будь он хоть статический, хоть динамический.
ВВ>> Вопрос, насколько необходимы именно статические, т.е. на этапе компайл-тайма, проверки в веб-приложении. VD>Создай тему в философии — обсуди эту тему, если она тебе интересна. Мне вот она не интересна. У меня даже сомнений нет, что статика всегда лучше динамики, так как чем раньше будет выявлена ошибка тем лучше. Главное, чтобы статика не делала софт менее функциональным и удобным. VD>Как я понял цель проекта как раз получить статическую типизацию при сохранении простоты и удобства разработки сайтов присущих РОР-у.
Мне казалось, задача создать фреймворк, который позволяет разрабатывать веб-приложения, используя функциональную парадигму. И не в стиле "здесь ввернем палу лямбд и ФВП", а *целиком*. Будет ли там только статика или статика+динамика или еще как-то — вообще вопрос вторичный.
ВВ>>В итоге те статические проверки, которые ты добавишь, могут мало чем отличаться от динамических. Важнее, чтобы они в принципе были. И в Руби они есть (а вот в JS, кстати, отсутствуют). VD>Это форменная чушь просто потому, что компиляцию всегда можно запустить до рантайма, а вот рантайм-проверки никода нельзя сделать во время компиляции.
И что? В веб-приложении стадия компиляции семантически отсутствует. Тот же АСП.НЕТ как ты сам написал прекрасно умеет прикидываться полностью динамическим приложением. И с точки зрения разница когда конкретно происходит проверка будет уже не столь важной.
Да и "рантайм-проверки" спокойно делаются во время компиляции. Для того же Питона есть куча верификаторов, которые проверяют код до запуска.
VD>В общем, дай человеку хоть что-то сделать. Не топи порыв энтузиазма в гнилой философии! VD>Пойми, я тоже обожаю по-филосовствовать. Но нужно где-то остановиться. В какой-то момент философия теряет смысл и становится бессмысленным давлением на моги окружающих.
А он и так делает, никто порыв не топит.
Если мои скромные и аккуратные ремарки способны утопить порыв, то видимо никакого порыва и не было.
Здравствуйте, VladD2, Вы писали:
Z>>>Тулкит это линк. Насчет неповоротливых классов — один из краеугольных камней фреймворка это передача данных во view, я очень надеюсь передавать туда анонимные типы, оставляя их статически типизированными. Но не стал заявлять, пока не изучу немерл получше. ВВ>>А что потом делать с этими анонимными типами? Нужны алгебраические типы. VD>Вот здесь — согласен!
А с чем не согласен? Тебе хочется хочется "более статически-типизированного" ASP.NET MVC?
Вот только там:
— нет декларативной валидации
— генерации вьюх это текстовый шаблон
— для простых случаев есть дикая redundancy в описаниях модели
и так далее и тому подобное
И как только мы введем ADT — ведь и модель должна быть представлена как ADT, наверное — это кардинально изменит просто все.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>>>А что потом делать с этими анонимными типами? Нужны алгебраические типы. VD>>Вот здесь — согласен!
ВВ>А с чем не согласен?
С тем, что варианты — хорошее предсавление для многих вещей.
ВВ>Тебе хочется хочется "более статически-типизированного" ASP.NET MVC?
И это тоже.
ВВ>Вот только там: ВВ>- нет декларативной валидации
И сделать нельзя?
ВВ>- генерации вьюх это текстовый шаблон
Плохо. Тут как раз нужен ДСЛ который бы работал с некой объектной моделью — View AST.
ВВ>- для простых случаев есть дикая redundancy в описаниях модели
Устраним.
ВВ>и так далее и тому подобное
Устраним.
ВВ>И как только мы введем ADT — ведь и модель должна быть представлена как ADT, наверное — это кардинально изменит просто все.
Хз. Надо думать. Вот то что формат View лучше оформить в виде вариантов я вижу уже отчетливо. Ее тогда можно будет удобно трансформировать и контролировать корректность выходного формата. Плюс весь эскейпинг можно на это дело повесить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Я не считаю, что "динамика круче". Я вообще не оперирую такими понятиями как "круче" или "некруче". ВВ>У динамики есть свои преимущества. Строить проект на том, что динамика — это баг, который нужно исправить, как-то не совсем правильно. Возможно, есть неполное представление о том, что дает динамическая типизация.
А я считаю, что динамика — это почти всегда зло. Иногда, конечно, необходимо. Но если можно без нее, то нужно без нее. Динамическая компиляция — 100% лучше чем динамическая типизация.
VD>>Пойди реализуй то что ты хочешь на C# 4.0. Благо он сегодня уже вышел в свет.
ВВ>Если ты "долго наблюдаешь за мной", то наверное должен был бы заметить, что "это" совсем не то, что я хочу.
Тогда опиши что ты хочешь. Но зачем навязывать человеку свою идеологию?
ВВ>И казалось бы зачем мне шарповые рельсы? Мне вообще не нравится ASP.NET MVC, будь он хоть статический, хоть динамический.
Ну, значит создай свой проект, альтернативный, и реализуй свои идеи. Я пока их даже понять не могу. Со стороны кажется, что у тебя только букет противоречий.
VD>>Как я понял цель проекта как раз получить статическую типизацию при сохранении простоты и удобства разработки сайтов присущих РОР-у.
ВВ>Мне казалось, задача создать фреймворк, который позволяет разрабатывать веб-приложения, используя функциональную парадигму. И не в стиле "здесь ввернем палу лямбд и ФВП", а *целиком*. Будет ли там только статика или статика+динамика или еще как-то — вообще вопрос вторичный.
Ну, кому-то из нас точно что-то казалось. Я ФП рассматриваю как инструмент позволяющий решать задачи, а не как смоцель. Мне важна декларативность. А уж как ее достичь дело десятое.
ВВ>>>В итоге те статические проверки, которые ты добавишь, могут мало чем отличаться от динамических. Важнее, чтобы они в принципе были. И в Руби они есть (а вот в JS, кстати, отсутствуют). VD>>Это форменная чушь просто потому, что компиляцию всегда можно запустить до рантайма, а вот рантайм-проверки никода нельзя сделать во время компиляции.
ВВ>И что? В веб-приложении стадия компиляции семантически отсутствует. Тот же АСП.НЕТ как ты сам написал прекрасно умеет прикидываться полностью динамическим приложением. И с точки зрения разница когда конкретно происходит проверка будет уже не столь важной.
Нет. Не заметил. Я заметил, что страница со некорректным кодом выдает сбой сразу при компиляции страницы, а не тогда когда управление дойдет до некой точки. И сообщение будет весьма специфическим.
Более того, я предпочитаю именно такие сообщения, а не исключения. Чем их меньше, тем лучше.
ВВ>Да и "рантайм-проверки" спокойно делаются во время компиляции. Для того же Питона есть куча верификаторов, которые проверяют код до запуска.
Ты не верно понимаешь суть термина "ранатйм-проверка".
ВВ>А он и так делает, никто порыв не топит.
Слава богу! Другой бы офигел и бросил бы.
ВВ>Если мои скромные и аккуратные ремарки способны утопить порыв, то видимо никакого порыва и не было.
Надо знать меру.
Я вот тоже не в востроге, что мои идеи по реструктуризатору были отброшены. Но это его решение! И его реализация. Возможно первый блин будет комом, но он (и окружающие) получат опыт. Причем не эфимерный, а в виде реально работающего кода. И вот кода этот код можно будте хотя бы запустить в тестовом режиме, то можно убдет сказать что-то конкретное.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А я считаю, что динамика — это почти всегда зло. Иногда, конечно, необходимо. Но если можно без нее, то нужно без нее.
А откуда это утверждение? Дотнет хорош не в последнюю очередь благодаря как раз большим чисто динамическим возможностям. Статическая типизация означает, что часть проверок — всего лишь часть — выносится в компайл-тайм. Я же не против этого. Мне кажется неразумным отказываться от любой динамики в принципе, только потому что "это плохо".
Вам хочется DRY/DIE и статику, а мне хочется REPL
VD>Динамическая компиляция — 100% лучше чем динамическая типизация.
Ну я, честно говоря, с трудом себе представляю динамическую компиляцию для *всего* веб-решения.
VD>>>Пойди реализуй то что ты хочешь на C# 4.0. Благо он сегодня уже вышел в свет. ВВ>>Если ты "долго наблюдаешь за мной", то наверное должен был бы заметить, что "это" совсем не то, что я хочу. VD>Тогда опиши что ты хочешь.
Я хочу, чтобы если уж у нас и был бы MVC, то даже чисто теоретически View мог бы быть только View, и вся работа с данными всегда осуществлялась бы через контроллер, и чтобы это нельзя было сломать, даже если бы захотелось.
Я не хочу HTML как текста, хочу ДСЛ, HTML литералы, называй как хочешь.
Я не хочу class based OOP для описания бизнес-объектов, хочу ADT.
Я хочу декларативную валидацию.
Я хочу, чтобы между клиентом и сервером не было такой пропасти, и чтобы одинаковые задачи решались одинаково.
Ну и ДжаваСкрипт меня подзадолбал, если честно.
VD>Но зачем навязывать человеку свою идеологию?
Ну вообще-то я просто пытался понять *его* идеологию.
ВВ>>И казалось бы зачем мне шарповые рельсы? Мне вообще не нравится ASP.NET MVC, будь он хоть статический, хоть динамический. VD>Ну, значит создай свой проект, альтернативный, и реализуй свои идеи. Я пока их даже понять не могу. Со стороны кажется, что у тебя только букет противоречий.
У меня нет противоречий, я просто не придерживаюсь точки зрения типа "Х это плохо 100% случаев". Сформированной концепции у меня нет, только "хотелки".
VD>>>Как я понял цель проекта как раз получить статическую типизацию при сохранении простоты и удобства разработки сайтов присущих РОР-у. ВВ>>Мне казалось, задача создать фреймворк, который позволяет разрабатывать веб-приложения, используя функциональную парадигму. И не в стиле "здесь ввернем палу лямбд и ФВП", а *целиком*. Будет ли там только статика или статика+динамика или еще как-то — вообще вопрос вторичный. VD>Ну, кому-то из нас точно что-то казалось. Я ФП рассматриваю как инструмент позволяющий решать задачи, а не как смоцель. Мне важна декларативность. А уж как ее достичь дело десятое.
Я уже говорил — на мой взгляд ФП прекрасно подходит для веба. Поэтому да, можно сказать, что для меня это самоцель. Ибо сейчас вещи доступные в ФП из коробки зачастую приходится имитировать слабо предназначенными для этого средствами.
ВВ>>И что? В веб-приложении стадия компиляции семантически отсутствует. Тот же АСП.НЕТ как ты сам написал прекрасно умеет прикидываться полностью динамическим приложением. И с точки зрения разница когда конкретно происходит проверка будет уже не столь важной. VD>Нет. Не заметил. Я заметил, что страница со некорректным кодом выдает сбой сразу при компиляции страницы, а не тогда когда управление дойдет до некой точки. И сообщение будет весьма специфическим.
Да ради бога, переопределил у тебя кто-нибудь оператор + и стал у тебя компилироваться код, который складывает Foo и Bar. Что значит корректно/некорректно?
Зачастую нам на этапе компиляции известно не какие операции можно совершать над типом, а какие контракты этот тип реализует. А свалится ли он при каком-нибудь ConvertToInt32 — известно только в рантайме.
Не та эта область ИМХО, чтобы шашкой махать. У тебя все равно куча вещей, которые вылезут в рантайме только. А динамическая типизация ведь и плюсы свои дает.
VD>И сообщение будет весьма специфическим.
Э, а в чем "специфичность"?
Пишем на Руби:
x = 2
y = "str"
puts x + y
Ошибка:
C:/temp/ruby.rb:ХХ:in `+': String can't be coerced into Fixnum (TypeError)
VD>Более того, я предпочитаю именно такие сообщения, а не исключения. Чем их меньше, тем лучше. ВВ>>Да и "рантайм-проверки" спокойно делаются во время компиляции. Для того же Питона есть куча верификаторов, которые проверяют код до запуска. VD>Ты не верно понимаешь суть термина "ранатйм-проверка".
Я верно понимаю суть термина "проверка". Если нужные тебе проверки можно сделать до запуска на исполнение, значит искомая цель достигнута. Разве нет?
В АСП.НЕТ, к слову, именно такая модель. Компиляции как таковой нет. Если хочешь — можешь запустить валидацию. Не хочешь — сразу открывай в браузере.
К слову — к этому они пришли после сурового коде-бехаинда в первых версиях, где студия по сути заставляла сначала билдить весь проект в ДЛЛ.
Не зря ведь, а?
ВВ>>А он и так делает, никто порыв не топит. VD>Слава богу! Другой бы офигел и бросил бы.
А что я такого сказал-то?
Я был предельно вежлив, с пеной у рта ничего не доказывал. Даже не знаю, как еще можно.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>>>А что потом делать с этими анонимными типами? Нужны алгебраические типы. VD>>>Вот здесь — согласен! ВВ>>А с чем не согласен? VD>С тем, что варианты — хорошее предсавление для многих вещей.
В смысле ты с этим не согласен?
ВВ>>Тебе хочется хочется "более статически-типизированного" ASP.NET MVC? VD>И это тоже.
Зачем тебе вообще MVC?
Если сделать все наши хотелки, от него останутся рожки да ножки.
ВВ>>Вот только там: ВВ>>- нет декларативной валидации VD>И сделать нельзя?
Как? Надо думать. В ХМЛ-е это by design как бы.
По идее должен быть "формат" специфицирующий модель. Это могут быть и метаданные самих ADT модели.
ВВ>>- генерации вьюх это текстовый шаблон VD>Плохо. Тут как раз нужен ДСЛ который бы работал с некой объектной моделью — View AST.
А ты Ur/Web смотрел?
ВВ>>И как только мы введем ADT — ведь и модель должна быть представлена как ADT, наверное — это кардинально изменит просто все. VD>Хз. Надо думать. Вот то что формат View лучше оформить в виде вариантов я вижу уже отчетливо. Ее тогда можно будет удобно трансформировать и контролировать корректность выходного формата. Плюс весь эскейпинг можно на это дело повесить.
Модель надо оформить в виде ADT. Вью — это трансформатор. В случае с ХМЛ-ем Вью — это XSLT.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>В АСП.НЕТ, к слову, именно такая модель. Компиляции как таковой нет. Если хочешь — можешь запустить валидацию. Не хочешь — сразу открывай в браузере.
Ну и скомпилирует тебе веб-сервер для каждой открытой aspx страницы временную динамическую сборку.
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, Воронков Василий, Вы писали: ВВ>>В АСП.НЕТ, к слову, именно такая модель. Компиляции как таковой нет. Если хочешь — можешь запустить валидацию. Не хочешь — сразу открывай в браузере. H>Ну и скомпилирует тебе веб-сервер для каждой открытой aspx страницы временную динамическую сборку.
Нужны алгебраические типы.
.
