Здравствуйте, VladD2, Вы писали:
ВВ>>XLinq слишком "низкоуровневый", я же о говорю проблемно-ориентированной, так сказать, типизации. VD>Ну, и как ты это себе видешь? Ведь для проблемно-ориентированной нужно ведь специализированные типы описывать.
Ну так и вижу — описывать специализированные типы. На самом деле их зачастую так или иначе приходится описывать. Если интерфейс мало-мальски сложный, то без какой-то промежуточной структуры данных никуда.
Я представляю, что, скажем, для того же меню есть некая иерархия типов — вполне можно сделать так, что она будет описываться очень лаконично. При этом каждому типу в данной иерархии соответствует свой шаблон, отвечающий за генерацию HTML. По большому счету берем XML/XSLT и портируем в Си-подобный синтаксис
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>По большому счету берем XML/XSLT и портируем в Си-подобный синтаксис
VD>Я тебе уже сказал, что XML описывается за 3 минуты. К тому уже есть XLinq.
Что-то ты тормозишь, мне кажется. Нет задачи XML в Немерле "портировать". Есть задача описывать то же, что и в ХМЛ, но другими средствами. Например, есть XML:
Здравствуйте, VladD2, Вы писали:
VD>Как продвигаются дела?
Не считая того, что было мало времени мог уделять проекту — нормально, шлифовал миграции. Заинтересовал коллегу, он сейчас делает пару интересных макросов к ним, как доделает — напишу доку по миграциям и мэйлстоун закрою.
VD>Есть ли сложности?
МС миграций закончен, думаю над следующим МС. Для него мне нужно уметь:
Пробежаться по сборке, найти все контроллеры, перебрать их методы, узнать сигнатуры. По ним сгенерить классы, (хорошим бонусом будет возможность догенерить сами контроллеры, боюсь, что это невохможно).
Пробежаться по проекту, найти файлы в определенных папках. По ним тоже сгенерить классы.
Пока не знаю что из этого вызовет большие сложности, если заранее подскажешь будет хорошо.
Здравствуйте, Ziaw, Вы писали:
Z> Пробежаться по сборке, найти все контроллеры, перебрать их методы, узнать сигнатуры. По ним сгенерить классы,
Это возможно.
Z>(хорошим бонусом будет возможность догенерить сами контроллеры, боюсь, что это невохможно).
Вопрос только в том на основании чего их генерировать.
Z> Пробежаться по проекту, найти файлы в определенных папках. По ним тоже сгенерить классы.
Z>Пока не знаю что из этого вызовет большие сложности, если заранее подскажешь будет хорошо.
Проблемы могут возникнуть если пытаться генерировать типы по выражениям получаемым из тел методов. Дело в том, что в IDE тела методов обрабатываются в отложенном режиме и по многу раз (каждое редактирование может заставить обработать один или все методы).
Так что выбирая дизайн нужно постараться сделать так, чтобы данные (модель) по которым будет генерироваться кода были доступны без заглядывания внутрь тел методов. Например, в виде атрибутов или в виде типов. Ну, типа описываешь декларативно некий тип, а уже по нему генерируется модель, контроллер и т.п.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
Z>Вот это, кстати, мне больше понравилось http://groups.inf.ed.ac.uk/links/examples/
А мне совсем не нравится.
Z>Синтаксис близок к немерлу.
Синтаксис дело десятое.
Главно что что urweb декларативный, а этот императивный.
Z>Но сгенеренный jscript похож на обфусцированный.
Это вообще дело десятое.
Тут чем быстрее и компактнее тем лучше. Читаемость генеренных жабаскриптов никого не интересует также как никого не интересует читаемость машинных кодов.
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
Z>>Синтаксис близок к немерлу. WH>Синтаксис дело десятое. WH>Главно что что urweb декларативный, а этот императивный.
Гм... Я бы сказал, что он чуть менее чист функционально чем хаскель. Не декларативным он от этого не становится. Всю логику там можно реализовать на замыканиях и continuations(продолжениях?). Где там императив-то? Неужели for? Это насквозь декларативный сахар для list comprehension.
Хотя возможность включения императива вполне в духе Nemerle и должна бы приветствоваться.
Z>>Но сгенеренный jscript похож на обфусцированный. WH>Это вообще дело десятое. WH>Тут чем быстрее и компактнее тем лучше. Читаемость генеренных жабаскриптов никого не интересует также как никого не интересует читаемость машинных кодов.
В том то и дело, что он не компактен как минимум, потому и быстрым быть не может, т.к. генерит большой кусок рантайма внутрь страницы, что убивает кеширование. Впрочем это не суть важно.
fun waiting(id) client {
receive {
case MouseDown(elem) ->
if (isElementNode(elem) && (parentNode(elem) == getNodeById(id)))
dragging(id, elem)
else
waiting(id)
case MouseUp -> waiting(id)
case MouseOut(toElem) -> waiting(id)
}
}
fun dragging(id, elem) client {
receive {
case MouseUp -> waiting(id)
case MouseDown(elem) ->
if (isElementNode(elem) && (parentNode(elem) == getNodeById(id)))
dragging(id, elem)
else
waiting(id)
case MouseOut(toElem) ->
if (isElementNode(toElem) && (parentNode(toElem) == getNodeById(id))) {
swapNodes(elem, toElem);
dragging(id, elem)
} else dragging(id, elem)
}
}
В варианте ur/web нет ничего и близко похожего.
Причем ur/web можно сделать еще лучше
fun draggableList title items =
itemSources <- List.mapM source items;
draggingItem <- source None;
return <xml>
<h2>Great {[title]}</h2>
<ul onmouseout={set draggingItem None}>
<li each itemSource in itemSources
onmousedown={set draggingItem (Some itemSource)}
onmouseup={set draggingItem None}
onmouseover={
di <- get draggingItem;
case di of
| None => return ()
| Some di =>
original <- get di;
movedOver <- get itemSource;
set di movedOver;
set itemSource original;
set draggingItem (Some itemSource)
}
>
<dyn item=itemSource>{[item]}</dyn>
</li>
</ul>
</xml>
Принципиальная разница в том что links манипулирует уже готовыми кусками страници причем весьма императивно.
ur/web использует связку source/dyn которая работает исключительно с исходными данными.
При изменении source все зависимые от него dyn перестраиваются. Причем одному dyn'у никто не мешает быть зависимым от нескольких source.
Z>Хотя возможность включения императива вполне в духе Nemerle и должна бы приветствоваться.
Нет. Не должна.
Z>В том то и дело, что он не компактен как минимум, потому и быстрым быть не может,
Это утверждение более чем спорно.
Z>т.к. генерит большой кусок рантайма внутрь страницы, что убивает кеширование.
То что они вообще кладут скрипты внутрь страници это плохо.
Все скрипты должны идти отдельным файлом. Причем имя файла нужно генерировать на основе например sha1 от его содержимого и выставлять вечное кеширование.
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
