Здравствуйте, Andrey_Pilya, Вы писали:
A_P>Здравствуйте, c-smile, Вы писали:
CS>>Декораторы расширяют синтаксис JavaScript добавляя chained flat calls фичу, объявление:
CS>>CS>>@decor1 p11 p12 ... p1N @decor2 p21 p22 ... p2N @decor3 p31 p32 ... p3N function Foo(fp1 ... fpN ) { ... }
CS>>
A_P>я бы еще понял, если бы этот синтаксис прятался в комментарии, типа что бы сохранить обратную совместимость.
A_P>но раз уж вводятся новые конструкции, то зачем таким боком?
A_P>получается слишком много значков, сложный шифр и совсем не видно глазом, как его читать/понимать.
A_P>плюс, этот синтаксис крайне упрощен сугубо под одну задачу (как минимум, он декорирует только одну функцию,
A_P>а вот для "бутерброда" типа : {обработчик bubbling + обработчик sinking} уже прийдется приумывать...)
Ничего не надо придумывать. Вот пример того как на одну функцию (SumInt) цепляется два декоратора (precondition и postcondition):
@params #integer #integer
@returns #integer
function SumInt(a,b)
{
return a + b;
}
По-моему достаточно читабельно. Декораторы фактически образуют pipe: функция передается из одного декоратора в другой.
Декоратор может вставить свою прослойку (function call wrapper). Вот как это имплментировано в реале:
// decorator '@params' - verification of parameters passed to the function
function @params(func, param_types..)
{
return function(params..)
{
var n = 0;
for(var p in params)
if(typeof p != param_types[n++])
throw String.printf("parameter %d, expected %s but got %s", n, param_types[n-1], typeof p);
return func.apply(this,params);
}
}
// decorator '@returns' - verification of returned value of the function
function @returns(func, return_type)
{
return function(params..)
{
var rv = func.apply(this,params);
if( typeof rv != return_type )
throw String.printf("expected to return %s but got %s", return_type, typeof rv);
return rv;
}
}
pipelining декораторов это фактически модель используемая Lisp. Здесь же она работатет в строго отведенном для того месте.
CS>>фактически транслируется в такую последовательность:
CS>>CS>>var Foo = @decor1 (p11, p12, ..., p1N,
CS>> @decor2 (p21, p22, ..., p2N,
CS>> @decor3 (p31, p32, ..., p3N,
CS>> function(fp1 ... fpN)
CS>> {
CS>> ...
CS>> }
CS>>)));
CS>>
A_P>почему бы так не писать сразу? зачем опускать скобки и делать код ограниченнее и сложнее?
A_P>в такой нотации, например, нет причин запрещать многократное появление слова "function"... (другой вопрос, что само по себе
A_P>оно уже не нужно, но свой пример нотации я уже приводил)
Не каждый человек в состоянии эту красоту взглядом оценить т.е. понять. А это непонимание — перманентный источник ошибок.
CS>>Собственно декораторы это syntax islands в которых работает то что я называю flat syntax который используют
CS>>например Ruby. Имея в языке две системы можно получить преимущества двух систем.
CS>>Скажем можно встраивать в язык различные DSL имея при этом возможность использования классической С alike нотации.
A_P>миф. что бы встраивать в язык DSL нужна не вторая нотация, а механизм эскейпинга двух одинаковых нотаций друг от друга (и от всего остального).
Теоретически — наверное, практически — не ясно зачем встраивать сферческого вакуумного коня в его же но кубического.
A_P>да, схем эскейпинга может быть несколько: Html от JS или JS от Html или JS от CSS или Meta-JS от JS....
К сожалению задача надежного практического решения не имеет. К тому же без кооперации разных нотаций и невозможная в большинстве случаев.
Ну скажем в web/html она так и не решена.
<script>
<!--
document.write("</script>");
-->
</script>
script здесь должен знать про "<!--" и "-->"
В PHP вообще напридумывали чертову силу всяких escapement'ов. Но надежного решения тоже нет.
Вот например такая загогулина:
<?php // Html safe containers
$myOutput = <<<MYHTMLSAFEOUTPUT
<?xml version="1.0"?>
<html>
<title>PHP Example</title>
<body>
<p>...all sorts goes here...</p>
</body>
</html>
MYHTMLSAFEOUTPUT;
echo $myOutput;
?>
Здравствуйте, c-smile, Вы писали:
A_P>>я бы еще понял, если бы этот синтаксис прятался в комментарии, типа что бы сохранить обратную совместимость.
A_P>>но раз уж вводятся новые конструкции, то зачем таким боком?
A_P>>получается слишком много значков, сложный шифр и совсем не видно глазом, как его читать/понимать.
A_P>>плюс, этот синтаксис крайне упрощен сугубо под одну задачу (как минимум, он декорирует только одну функцию,
A_P>>а вот для "бутерброда" типа : {обработчик bubbling + обработчик sinking} уже прийдется приумывать...)
CS>Ничего не надо придумывать. Вот пример того как на одну функцию (SumInt) цепляется два декоратора (precondition и postcondition):
я говорю о декораторе, который декорирует 2 функции в один бутерброд, а не 2 декоратора на одну функцию
CS>По-моему достаточно читабельно. Декораторы фактически образуют pipe: функция передается из одного декоратора в другой.
CS>pipelining декораторов это фактически модель используемая Lisp. Здесь же она работатет в строго отведенном для того месте.
Pipeline — это просто вызов цепочки функций? которые друг дружке передают нечто.... это просто вызов цепочки функций
A_P>>почему бы так не писать сразу? зачем опускать скобки и делать код ограниченнее и сложнее?
A_P>>в такой нотации, например, нет причин запрещать многократное появление слова "function"... (другой вопрос, что само по себе
A_P>>оно уже не нужно, но свой пример нотации я уже приводил)
CS>Не каждый человек в состоянии эту красоту взглядом оценить т.е. понять. А это непонимание — перманентный источник ошибок.
...посмотрим, конечно, но кажется мне, что чем больше неявных вызовов и витиеватостей синтаксиса — тем больше непонимания,
того, что на самом деле происходит. выливается это в "копи-паст" программирование, с аргументацией: "не знаю что это, но вот тут работает". Со временем количество шаманских трюков переваливает за критическое и ошибки лезут фонтаном.
CS>script здесь должен знать про "<!--" и "-->"
потому, что и HTML и JS — это эгоистичные синтаксические извращения.
куда хуже обстоит дело, нужно писать код, который генерит JS, который генерит Html, который....
(и это не сферический конь, это библиотеки контролов и т.п.)
CS>В PHP вообще напридумывали чертову силу всяких escapement'ов. Но надежного решения тоже нет.
CS>Вот например такая загогулина:
CS>CS><?php // Html safe containers
CS>$myOutput = <<<MYHTMLSAFEOUTPUT
CS><?xml version="1.0"?>
CS><html>
CS> <title>PHP Example</title>
CS> <body>
CS> <p>...all sorts goes here...</p>
CS> </body>
CS></html>
CS>MYHTMLSAFEOUTPUT;
CS>echo $myOutput;
CS>?>
CS>
это они не придумали, это они списали (Sh или Perl, уж не знаю, кто там первый..)
а что делать, если хочется в плоский файл засунуть длиннючий кучок стороннего бреда? можно в нем все кавычки эскейпить, но это лениво
вот и придумали когда-то в юниксе "строку-терминатор".
...но сегодня этим пользоваться врядли стоит.
Здравствуйте, c-smile, Вы писали:
А>>Ну што за черт...
А>>А>>self.on_click('button#up') do |event|
А>> #self == контейнер
А>> #event.target == кнопка
А>>end
А>>
CS>А вот как это будет использоваться (опять же на линейном JS):
CS>CS>self.on_click("button#up", function(evt)
CS> {
CS> // 'this' here is self
CS> // evt.target - the button
CS> });
CS>
CS>не так pretty как с Ruby. Как я уже сказал задача состоит в том чтобы дать JS возможность такие
CS>штуки описывать менее curly.
Дальше, мне кажется, уже чисто вопрос вкуса. По мне, пара лишних скобочков (я так понял, тебе не нравится исключительно "});" в конце), к тому же, привычных для всех жаваскриптеров (см. jQuery и все остальное в том же духе) — вполне приемлемый tradeoff. А новый, ни с чем не совместимый, кусок синтаксиса — не вполне приемлемый. Но это мое личное мнение.
Здравствуйте, Аноним, Вы писали:
А>>>Ну што за черт...
А>>>А>>>self.on_click('button#up') do |event|
А>>> #self == контейнер
А>>> #event.target == кнопка
А>>>end
А>>>
CS>>А вот как это будет использоваться (опять же на линейном JS):
CS>>CS>>self.on_click("button#up", function(evt)
CS>> {
CS>> // 'this' here is self
CS>> // evt.target - the button
CS>> });
CS>>
CS>>не так pretty как с Ruby. Как я уже сказал задача состоит в том чтобы дать JS возможность такие
CS>>штуки описывать менее curly.
А>Дальше, мне кажется, уже чисто вопрос вкуса. По мне, пара лишних скобочков (я так понял, тебе не нравится исключительно "});" в конце), к тому же, привычных для всех жаваскриптеров (см. jQuery и все остальное в том же духе) — вполне приемлемый tradeoff. А новый, ни с чем не совместимый, кусок синтаксиса — не вполне приемлемый. Но это мое личное мнение.
Добавлю к этому, что ситуация вообще характерна. Ты как бы наследуешь TIScript от JS, но последний тебе не нравится, кажется несимпатичным и неизящным, и ты добавляешь в свой язык "нормальные классы" (игнорируя прототипно-ориентированное ООП), декораторы (игнорируя свойственный JS стиль мета-программирования) и т.п.
Результат, возможно, с твоей точки зрения позволяет "всякие прикольные штуки", но изящества и внутренней стройности у нее существенно меньше, чем у JS или же "your-favourite-language", если бы он создавался с нуля. Твоя любимая цитата про коня и трепетную лань кажется здесь вполне уместной
