Здравствуйте, dimgel, Вы писали:
D>Если я правильно понял, то ты агитируешь на счёт того, что на правильных языках при правильном подходе мне не потребуется даже во фреймворке рефлексию использовать.
Я тебе больше скажу. Тебе даже само понятие фрэймворк не потрбуется, так как все будет реализовываться тем, что раньше называлось "библиотека". Только это будет библиотека макросов.
Вот пример такой библиотеки заменяющей фрэймворк: Nemerle on rails
А вот пример реализации шаблонрго движка редеренга XML-я реализованного в виде встроенного в язык DSL-я Nemerle.Xml: Пример использования. Исходники макроса.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Откровенно говоря, ни черта не понял — ни что оно делает, ни что из себя представляет.
Однако разглядел "using System.Reflection" в первой строчке. :-P
Здравствуйте, gandjustas, Вы писали:
WH>>Они вообще бяка. Даже для десктопа. G>Для десктопа ОК, иначе придется дофига всего писать.
Что писать?
G>MVVM как в WPF далеко не все проблемы решает. G>Хотя заложена очень здравая концепция: отделение логики (код) от представления (xaml) и все вместе от состояния (viewmodel). Все это связывается между собой мощным механизмом байндинга.
viewmodel должна быть реактивной.
А в WPF это достигается через страшные костыли.
G>Все красиво, но 100% работать не будет. Разметка не должна быть в файлах к кодом.
Осталось выяснить чем разметка не код.
G>В худшем случае наоборот: вкрапления кода в разметку, причем должна быть возможность править разметку без перекомпиляции.
А зачем?
Тем более что без перекомпиляции у нас не будет проверки типов.
G>А мне либа совсем не нравится. Создавать ручками viewModel в динамически типизрованном языке, где есть eval — моветон.
Хочешь eval используй. В чем проблема то?
G>Лучше так: http://msdn.microsoft.com/en-us/magazine/ee819084.aspx G>С синтаксисом вроде неочень, но ms сейчас такие фичи в jQuery пишет вроде уже можно пощупать: G>http://weblogs.asp.net/scottgu/archive/2010/05/07/jquery-templates-and-data-linking-and-microsoft-contributing-to-jquery.aspx
Что-то там все очень неуклюже.
G>Реквестирую killerapp для Nemerle2: ViewEngine для ASP.NET MVC 3 c синтаксисом Razor со всеми плюшками типа автоматической подсветки синтаксиса.
Осталось понять нахрена после этого будет нужен сам ASP.NET?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Гламурненько. Хотя начиная с "_ =" в строке 50 и всё что ниже не понял, так что смотрю только на "xml <# #>". Я так понимаю, главный пойнт в том, что это именно на макросах, а не встроенная в язык поддержка XML, как в скале. Вопрос, кстати: а эта штука умеет оборачивать в if/unless группу элементов, чтобы в каждом элементе группы не дублировать условие?
В догонку про замечание Влада, что будут библиотеки макросов вместо фреймворков — "фреймворк" и "библиотека" ИМХО тут синонимы. Понятно, что фреймворки на языке с поддержкой МП (ФП,ООП,АБЫВАРЛГ) будут использовать МП (ФП,ООП,АБЫВАРЛГ).
Здравствуйте, dimgel, Вы писали:
VD>>Пример использования.
D>Откровенно говоря, ни черта не понял — ни что оно делает, ни что из себя представляет.
Это наверно потому что я косой . Я не туда ссылку дал.
Так понятнее: AsyncTest.n? (подсветка кода кривая, не обращайте внимание на нее).
D>Однако разглядел "using System.Reflection" в первой строчке. :-P
Это был стандартный файл которые Visual Studio добавляет к любому проекте. В нем описывается метаинформация проекта. Я просто нечаянно ссылкой промазал. Смотреть на этот файл бессмысленно. А System.Reflection там видимо потому, что один из атрибутов описан в этом пространстве имен.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dimgel, Вы писали:
D>Гламурненько. Хотя начиная с "_ =" в строке 50 и
Немерле выдает предупреждение когда возвращаемое значение игнорируется (обычно это ошибка).
Но когда действительно нужно проигнорировать возвращаемое значения его присваивают универсальной черной дыре которая ест все.
D>всё что ниже не понял, так что смотрю только на "xml <# #>".
А там ничего особо интересного нет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
В принципе, только на это и надо смотреть. Остальное просто тесты функциональнсоти. Так как цель у них была только проверить возможности, то понять там что либо сложно. Бессмысленные действия они и есть бессмысленные действия .
Но на всякий пожарный распишу что к чему:
// запуск процесса, так как там путь к html-страничке, это приводит к открытию страницы браузером выбранным по умолчанию
50 _ = Diagnostics.Process.Start(path);
51 }
52
// Запуск тестовых функции с передачей в нее "типов" (объектов рефлексии описывающих типы)
// Рефлексия здесь используется только как источник данных.
// Так же стоит обратить внимание на то, что функции являются локальными функциями, т.е. функциями объявленными внутри методов.
53 makeClassInfoPage(typeof(XAttribute));
54 makeClassInfoPage(typeof(TestClass));
55
// Это объявление nullable-объекта, т.е. объекта вэлью-типа (int в данном случае) который таки может принимать значение null. Это специфика дотнета.
56 def z : int? = 42;
// Это описание атрибутов без "сахара" (т.е. без использования макроса), на уровне XML-AST.
57 def a = [XAttribute("LANG", "enu"), XAttribute("xx", "yy")];
// А это описание пустого тега "x" с использованием макроса.
58 def e1 = xml <# <x /> #>;
// Объявление с списка состоящего из двух атрибутов ("w" - описанного по месту без макроса и "x", описанного выше).
59 def elems = [XElement("w"), e1];
// Описание куска XML-я с блэкджеом и шлюхами. Последнее описываю отдельно:
// ns1:a=$z - описание атрибута ns1:a значение которого задается через переменную "z".
// ..$a - генерация сразу нескольких атрибутов на список которых ссылается переменная a. Синтаксис "..$выражение" - означает подставить в данное место значение списка.
// ..$elems - почти тоже самое что и в предыдущем случае, но список содержит элементы и, стало быть, раскрывается в набор элементов.
61 def res1 = xml <# <e a="a" ns1:a=$z ..$a>Text $e1<ns2:a ns2:aa="zz" xmlns:ns2="namespace-2"></ns2:a> abc ..$elems</e> #>;
62 WriteLine(res1); // Преобразование сгенерированного XML-я в текст и его вывод консоль.
63 def name = XName.Get("dyn"); // динамическое формирование имени.
// Генерация еще одного фрагмента ХМЛ-я.
// В данном случае:
// $name - задает (динамически) имя тега.
// $when (z.HasValue) - это встроенный условный оператор. Если условие "z.HasValue" ложно, тег не выводится (т.е. весь тег исчезает).
64 def res2 = xml <# <ns2:Папа xmlns:ns2="namespace-2"><$name $when (z.HasValue) ns1:a="123"/></> #>;
65 WriteLine(res2); // вывод сформированного ХМЛ-я на консоль.
66
67 def ƱƲƳ = 123; // Демонстрация поддержки юникода в немерле. К делу не относится.
68 WriteLine(ƱƲƳ);
D>Я так понимаю, главный пойнт в том, что это именно на макросах, а не встроенная в язык поддержка XML, как в скале.
Именно! Это, кроме всего прочего, позволяет сделать собственные движки с собственным блэкджеком и шлюхами.
D>Вопрос, кстати: а эта штука умеет оборачивать в if/unless группу элементов, чтобы в каждом элементе группы не дублировать условие?
Нет, и сделано это намеренно. if-ы в виде тегов выглядят безобразно, на мой взгляд. Если нужно работать с большим количеством элементов, то нужно просто использоваться ФП и слайсы ($xxx или ..$xxx), внутри которых можно использовать любые конструкции языка (в том числе функции высшего порядка).
Реализовать поддержку "групповых операторов" не сложно, но на мой взгляд — это приведет к замусориванию кода.
D>В догонку про замечание Влада, что будут библиотеки макросов вместо фреймворков — "фреймворк" и "библиотека" ИМХО тут синонимы. Понятно, что фреймворки на языке с поддержкой МП (ФП,ООП,АБЫВАРЛГ) будут использовать МП (ФП,ООП,АБЫВАРЛГ).
Ну, в общем — да, конечно библиотека макросов по мощности аналогичнна фрэймворку. Но все же простота использования и возможность встраивания в основной язык у макросов выше. По этому использование макро-библиотек выглядит как использование библиотек, а не как использование фрэймворков. Я специально акцентировал на этом внимание, так как это дорогого стоит.
Плюс используя макросы мы можем спокойно обходиться без рефлексии и других проявлений динамики. Опять же я не говорю, что динамика вообще ненужна, но как правило она закрывает прорехи в языке или технологии. Мое мнение такое. Динамика вещь очень полезная, но по делу она нужна крайне редко. И надо стараться по возможности обходиться без нее. И только тогда когда динамика дает реальные преимущества не достижимые другими путями (как, например, рантайм-загрузка плагинов), на использовать ее.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dimgel, Вы писали:
D>Дык задача была простая: удобный модуль форм, без необходимости пользователю фреймворка писать кучу boilerplate-кода. В частности, значения атрибута name для <input/> берутся через рефлексию из имён полей класса. Т.е. в шаблоне формы юзер пишет D>
где значение поля берётся из одноимённого поля переданного в форму DTO (вот эту работу с состоянием я возможно сделаю явной, добавляя геттеры/сеттеры в объявление поля, хотя букв в пользовательском коде сразу станет намного больше).
Что касается решения на динамике, то я бы предпочел иметь лямбды. Ими можно было и астрагироваться от типа свойства, и обеспечить ленивого исполнение.
Но реально красивое решение тут можно было бы сделать если воспользоваться метапрограммированием. Приведу еще одну ссылку на Nemerle on rails. Погляди как там в стадию компиляции переносится не только работа с веб-формами и контроллерами, но и реструктуризация БД.
VD>>Сам факт использования рефлексии зачастую является признаком проблем.
D>Во всех известных мне java-фреймворках рефлексия используется чуть более, чем всегда.
Дык, как тут уже сказали, это проблема Явы.
Я не занимаюсь вебом, но все же за последние время рефлексия мне понадобилась только один раз и то только от лени и потому, что там вообще не важна скорость была.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Это наверно потому что я косой . Я не туда ссылку дал. VD>Так понятнее: AsyncTest.n? (подсветка кода кривая, не обращайте внимание на нее).
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, gandjustas, Вы писали:
WH>>>Они вообще бяка. Даже для десктопа. G>>Для десктопа ОК, иначе придется дофига всего писать. WH>Что писать?
Код для протаскивания состояния между "запросами". Ведь на десктопе все объекты живут в памяти между запросами и ручное таскание выглядит как костыли.
G>>MVVM как в WPF далеко не все проблемы решает. G>>Хотя заложена очень здравая концепция: отделение логики (код) от представления (xaml) и все вместе от состояния (viewmodel). Все это связывается между собой мощным механизмом байндинга. WH>viewmodel должна быть реактивной. WH>А в WPF это достигается через страшные костыли.
Реактивной это как?
G>>Все красиво, но 100% работать не будет. Разметка не должна быть в файлах к кодом. WH>Осталось выяснить чем разметка не код.
Тем что править её могут люди далекие от программирования.
G>>В худшем случае наоборот: вкрапления кода в разметку, причем должна быть возможность править разметку без перекомпиляции. WH>А зачем?
см выше.
WH>Тем более что без перекомпиляции у нас не будет проверки типов.
Эта проблема решена в asp.net
G>>Лучше так: http://msdn.microsoft.com/en-us/magazine/ee819084.aspx G>>С синтаксисом вроде неочень, но ms сейчас такие фичи в jQuery пишет вроде уже можно пощупать: G>>http://weblogs.asp.net/scottgu/archive/2010/05/07/jquery-templates-and-data-linking-and-microsoft-contributing-to-jquery.aspx WH>Что-то там все очень неуклюже.
Да ты че?
jquery покачто самый лаконичный и мощный фреймворк.
G>>Реквестирую killerapp для Nemerle2: ViewEngine для ASP.NET MVC 3 c синтаксисом Razor со всеми плюшками типа автоматической подсветки синтаксиса. WH>Осталось понять нахрена после этого будет нужен сам ASP.NET?
Начинать надо с малого.
Здравствуйте, dimgel, Вы писали:
D>Гы, эта проблема перманентная. Но я пока не вижу, в какую сторону ползти. Что ты написал про атрибуты — это, как я понимаю, те же аннотации в java/scala, получаемые через рефлексию. На немерле примерчик бы, посмотреть как люди живут.
В немерле атрибуты могут быть мета-атрибутами. Выглядят они как обычные атрибуты, но метаданных не порождают. Вместо этого они приводят к вызову некоторого макроса которые во время компиляции может что-то сделать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandjustas, Вы писали:
D>>На немерле примерчик бы, посмотреть как люди живут. G>На Nemerle пока такого не сделано.
Ну, почему же? Кое-что есть. Я тут уже давал ссылки на Nemerle on rails.
G>http://www.asp.net/mvc
G>там правда много заботать придется чтобы разобраться. Но сейчас это ИМХО самый адекватный веб-фреймворк на статически типизированном языке.
Вот Nemerle on rails — это попытка прикрыть макросами его некрасивости.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandjustas, Вы писали:
G>Код для протаскивания состояния между "запросами". Ведь на десктопе все объекты живут в памяти между запросами и ручное таскание ыглядит как костыли.
Ничего не понял.
Что и зачем таскать?
WH>>viewmodel должна быть реактивной. WH>>А в WPF это достигается через страшные костыли. G>Реактивной это как?
Примерно вот так: http://knockoutjs.com/documentation/observables.html#mvvm_and_view_models
WH>>Осталось выяснить чем разметка не код. G>Тем что править её могут люди далекие от программирования.
И что? Как это отменяет тот факт что разметка это тоже код?
WH>>Тем более что без перекомпиляции у нас не будет проверки типов. G>Эта проблема решена в asp.net
Она решена компиляцией.
G>Да ты че? G>jquery покачто самый лаконичный и мощный фреймворк.
А как по мне так Knockout лаконичней.
WH>>Осталось понять нахрена после этого будет нужен сам ASP.NET? G>Начинать надо с малого.
Мне всетки интересно зачем ASP.NET?
Рендрер у нас свой.
Маршилинг свой.
Поиск серверных обработчиков свой.
Кешировать кроме автогенеренных жабаскриптов и статики нам нечего.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, dimgel, Вы писали:
D>Собсна главный вызов здесь — это само словосочетание "stateless component" (натуральный оксюморон), отсюда и всякие метания на тему геттеров/сеттеров/thread-local. Не вижу пока, как оно в итоге может быть, но чувствую, что определяющими окажутся ограничения языка.
Дык выкинь из лексикона слово компонент и все встанет на свои места.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В прочем, в Яве по идее любой класс должен храниться в class-файлах. Так что не ясно как они умудряются делать специализации в таких условиях.
Да способов миллион на самом деле, было бы желание.
В частности, scala компилятор навешивает на класс аннотацию ScalaSignature, которая в value хранит в сжатом виде всё, что нужно. Этот же компилятор читает эту аннотацию.
Здравствуйте, dimgel, Вы писали:
D>Тем не менее, Wicket очень многие очень хвалят, а дыма без огня не бывает.
Уверен, что эти многие дальше явы и С++ не заглядывали. Для веба бейсвительно куда лучше опдходят идеи ФП и MVC.
D>Контроль над HTML-кодом я тоже люблю иметь полный, но надеюсь, что смогу если не решить, то хотя бы обойти эту проблему, если не буду увлекаться навороченными компонентами в составе фреймворка, а вместо этого обеспечу простой для пользователей способ добавлять свои. Ведь "компоненты" по большому счёту — это просто способ декомпозиции кода. Есть у меня надежда, что stateless component выйдет в итоге тупо пассивным хранилищем для двух ортогональных вещей: class Component(widget, eventHandler), из которых виджет — тупо функция Data => HTML. В этом случае, для пользователя не будет составлять никаких проблем наклепать нужных ему виджетов, генерирующих в точности нужный ему HTML.
Мне кажется, что сама идея эмуляции GUI-ёвостей которая здесь просматривается — это не лучшая идея. Она противоречит веб-у. Веб страницы намного разумнее рассматривать как набор трансформаций, а не как какие-то там живущие дольше страницы компоненты.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, gandjustas, Вы писали:
G>>Код для протаскивания состояния между "запросами". Ведь на десктопе все объекты живут в памяти между запросами и ручное таскание ыглядит как костыли. WH>Ничего не понял. WH>Что и зачем таскать?
Ну попробуй написать десктопный UI с изоляцией "запросов" друг от друга.
WH>>>viewmodel должна быть реактивной. WH>>>А в WPF это достигается через страшные костыли. G>>Реактивной это как? WH>Примерно вот так: http://knockoutjs.com/documentation/observables.html#mvvm_and_view_models
То есть ты фактически предлагаешь все сделать через DependencyProperty (в терминах .NET), тогда чем тебя WPF не устраивает?
WH>>>Осталось выяснить чем разметка не код. G>>Тем что править её могут люди далекие от программирования. WH>И что? Как это отменяет тот факт что разметка это тоже код?
Только разметку обычно правят не те люди, которые пишут логику.
WH>>>Тем более что без перекомпиляции у нас не будет проверки типов. G>>Эта проблема решена в asp.net WH>Она решена компиляцией.
только никто мне не мешает поправить view на работающем сайте и при необходимости перекомпилировать его.
G>>Да ты че? G>>jquery покачто самый лаконичный и мощный фреймворк. WH>А как по мне так Knockout лаконичней.
В каком месте?
Ты считаешь задавание dependencyObservable лаконичнне выражения в двух фигурных скобках?
WH>>>Осталось понять нахрена после этого будет нужен сам ASP.NET? G>>Начинать надо с малого. WH>Мне всетки интересно зачем ASP.NET? WH>Рендрер у нас свой. WH>Маршилинг свой. WH>Поиск серверных обработчиков свой. WH>Кешировать кроме автогенеренных жабаскриптов и статики нам нечего.
В этом всем и проблема. Вы резко ограничили learnability вашего решения тем что у вас все свое.
Я уверен что asp.net mvc знают больше народу, чем nemerle, поэтому предпочел бы:
1)Написать контроллеры в asp.net mvc на Nemerle
2)Использовать view с синтаксисом razor на Nemrle
3)Для MetadataProvider и Binder использовать макросы (чтобы рефлексии не было)
4)DI и AOP тоже сделать на макросах
5)Генерить клиентские скрипты из кода на nemerle
Но я абсолютно не хочу изучать новый фреймворк с другой идеологией на nemerle. Аналогично я и F# WebTools не использовал слишком сильно он отличается от того что есть.
. Я не туда ссылку дал.
