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

S>Здравствуйте, anonymous, Вы писали:
A>>Ну а как ещё новые поведение и свойства добавлять элементам?
S>Через HTML+CSS+JavaScript.

Это не наш путь — слишком просто.

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

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

A>>А как тебе такое? Правда это не HTML, а XUL. (Извиняюсь, за большой кусок кода, посто это один рально работающий binding.)
CS>.поскипано.
A>>Теперь у нашей кнопки (здесь опитывается кнопка панели инструментов), есть свой конструктор, свои поля (в том числе и read only) и свои методы. А кроме того она ещё и реализует интерфейс nsIObserver, т. е. способна работать обсервером.
CS>Ну это мрак если честно. Это просто *не может быть* так сложно.

Это *не* сложно. У меня на освоение ушло не больше часа, при том, что раньше я вообще ничего не знал об XBL.

CS>Примерно так надо:
CS>

CS>CSS:
CS>div.Foo 
CS>{
CS>  prototype: Foo; // все <div class="Foo"> будут иметь этот behavior
CS>}
CS>Script:
CS>type Foo: Behavior
CS>{
CS>  function onMouse(evt) {}
CS>  function onKey(evt) {}
CS>  property something(v) { get return this.tag; }
CS>  function doSomething() { ... }
CS>}
CS>$("div.Foo").doSomething();
CS>

Вот знаешь, что мне не нравится в таком подходе? То, что JavaScript влез в CSS файл (prototype), и вообще не очевидно откуда взялся этот Foo.

CS>И вообще я буду вельми признателен если мне кто-нибудь объяснит
CS>почему связывание DOM элемента с набором функций (классом)
CS>нужно делать через XML — т.е. еще один язык?

Тут я согласен с . (http://rsdn.ru/Forum/Message.aspx?mid=2394796&only=1

Автор: .
Дата: 05.03.07

), XML позволяет описать данные и поведение, не привязываясь к языку. Т. е. машина получает стандартно описанные имя и аргументы, а уж что там за код за ними, её не интересует.

CS>Я похоже додолбил w3c что они решили реинкарнировать BECSS. Во всяком случае уже начали
CS>говорить о binding атрибуте.

Реинкарнировать они-то реинкарнировали, но опять через ж... то есть через XML:

http://www.w3.org/TR/becss/


CS>И вообще я буду вельми признателен если мне кто-нибудь объяснит
CS>почему связывание DOM элемента с набором функций (классом)
CS>нужно делать через XML — т.е. еще один язык?

Это типа круто.

c-smile wrote:

> Можно я еще раз повторю вопрос? Зачем там XM[b]L ?
Это спецификация, называется "Binding Language". Он не просто пара хандлеров... А язык описания байндинга.
Почитай http://www.w3.org/TR/xbl/ (правда там 2-я версия).
Почему это удобнее сделать в виде xml, а не в виде описания объектной модели, которая должна быть настолько
универсальна, чтобы удобно ложиться в модели всех ЯП (или хотя бы популярного большинтсва) — вопрос исключительно
флеймогонный.

> Зачем для задачи связки языка A с HTML нужен еще язык B?
Ну html тут на самом деле косвенно, тут и xul и прочая радость прикручивается.

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

CS>Это у тебя мантра такая "Ты совершенно не адекватен"?

Это правда. Ты выдаешь свое негативное отношение, за реальное положение дел.

VD>>IE7 будет на подавляющем большинстве компьютеров просто потом что он идет во всех апдэйтах и ставится с новыми версиями ОС.

CS>Ты логи сайта давно смотрел? Особенно статистику по броузерам?

И что я там увижу?

Поглядел... На нашем сайте IE6 на сегодня составляет 35%, а IE7 10%. В январе у IE7 было 7%. Раскладка по ОС 75% ХРюша.
Учитывая, что МС ввела дурной запрет на апгрэйд IE для "подозрительных" версий Виндовс, и то что многоие не в состоянии качать огромные апдэйты все развивается предсказуемо.
Со временем появятся разные SP3 для ХРющи и много народа перейдет на Висту. В итоге доля IE7 будет увеличиваться и прийдет к 30-40%.

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

A>Здравствуйте, c-smile, Вы писали:

A>>>А как тебе такое? Правда это не HTML, а XUL. (Извиняюсь, за большой кусок кода, посто это один рально работающий binding.)
CS>>.поскипано.
A>>>Теперь у нашей кнопки (здесь опитывается кнопка панели инструментов), есть свой конструктор, свои поля (в том числе и read only) и свои методы. А кроме того она ещё и реализует интерфейс nsIObserver, т. е. способна работать обсервером.
CS>>Ну это мрак если честно. Это просто *не может быть* так сложно.

A>Это *не* сложно. У меня на освоение ушло не больше часа, при том, что раньше я вообще ничего не знал об XBL.

У меня на освоение понятия JSON ушло 3 секунды — ровно сколько заняло прочтение определения.

CS>>Примерно так надо:
CS>>

CS>>CSS:
CS>>div.Foo 
CS>>{
CS>>  prototype: Foo; // все <div class="Foo"> будут иметь этот behavior
CS>>}
CS>>

A>Вот знаешь, что мне не нравится в таком подходе? То, что JavaScript влез в CSS файл (prototype), и вообще не очевидно откуда взялся этот Foo.

Напиши:

div.Foo 
{
  binding: Foo; 
}

Foo это символическое имя — некий ID. К конкретному языку отношения не имеющий.
Любой язык в состоянии выполнить запрос типа:

  for(var el in $$("*{binding}")) bind(el, el.style.binding, handlers);

и назначить соотв. handlers всем элементам имеющим описанный binding атрибут в CSS.

Здесь ничего нового по сранению с тем что сделали Ben Nolan, Simon Willison и FallenGods

var MySomeOtherBehavior
{
     onclick : function()
     {
        alert(this.innerHTML);
     }
     onmouseenter : function()
     {
        this.style.color = "#00ff00";
     }
}

var mybindings =
{
   "span.someother"    : MySomeOtherBehavior;
   "span.someanoother" : MySomeAnotherBehavior;
};
Behaviour.register(myrules);

CS>>И вообще я буду вельми признателен если мне кто-нибудь объяснит
CS>>почему связывание DOM элемента с набором функций (классом)
CS>>нужно делать через XML — т.е. еще один язык?

A>Тут я согласен с . (http://rsdn.ru/Forum/Message.aspx?mid=2394796&only=1

Автор: .
Дата: 05.03.07

), XML позволяет описать данные и поведение, не привязываясь к языку. Т. е. машина получает стандартно описанные имя и аргументы, а уж что там за код за ними, её не интересует.

Абстракция нужна но до определенных пределов. Как я написал выше для того чтобы сделать биндинг нужен 1 (один) атрибут в CSS.
Не нужно городить огород с описаниями функций и их вызовами across language domains, runtimes and different memory allocations schemas.
XBL это технически абсолютно безграмотное решение. Откуда эти идеи вообще все лезут? Кто-нибудь из практиков просил такое придумывать?
Народу в комитетах нужно изображать бурную деятельность как я понимаю...

И только не надо XUL туда лепить еще. Если XUL использует CSS то он может пользоваться механизмом behaviors точно так же как и HTML.

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

CS>>Я похоже додолбил w3c что они решили реинкарнировать BECSS. Во всяком случае уже начали
CS>>говорить о binding атрибуте.

M>Реинкарнировать они-то реинкарнировали, но опять через ж... то есть через XML:

M>http://www.w3.org/TR/becss/


CS>>И вообще я буду вельми признателен если мне кто-нибудь объяснит
CS>>почему связывание DOM элемента с набором функций (классом)
CS>>нужно делать через XML — т.е. еще один язык?

M>Это типа круто.

Угу. Зудит у них. Какая-то болезнь право слово про XML.
Надо ж его куда-то пристегнуть, уж больно это слово из трех букв теоретикам ндравится.

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

VD>Здравствуйте, c-smile, Вы писали:

CS>>Это у тебя мантра такая "Ты совершенно не адекватен"?

VD>Это правда. Ты выдаешь свое негативное отношение, за реальное положение дел.

Я тебе выдаю реальные цифры и реальные линки. А чем подтверждаешь ты свою беззаветную любофф?

VD>>>IE7 будет на подавляющем большинстве компьютеров просто потом что он идет во всех апдэйтах и ставится с новыми версиями ОС.

CS>>Ты логи сайта давно смотрел? Особенно статистику по броузерам?

VD>И что я там увижу?

VD>Поглядел... На нашем сайте IE6 на сегодня составляет 35%, а IE7 10%. В январе у IE7 было 7%. Раскладка по ОС 75% ХРюша.
VD>Учитывая, что МС ввела дурной запрет на апгрэйд IE для "подозрительных" версий Виндовс, и то что многоие не в состоянии качать огромные апдэйты все развивается предсказуемо.
VD>Со временем появятся разные SP3 для ХРющи и много народа перейдет на Висту. В итоге доля IE7 будет увеличиваться и прийдет к 30-40%.

У меня IE год назад был 70% сейчас 50%. Мозилла была в меньше 10% сейчас 35%.

Эти цифири так и называются — IE сливает воду.
Я не верю что если бы MS хотела держать IE то она допустила бы такую ситуацию.
Я как ты сам понимаешь достаточно хорошо представляю что такое rendering HTML/CSS и если я один могу забить IE7
по тестам на производительность то это должно о чем-то говорить.

Как я понимаю Microsoft как Интернет компании самим выгодно чтобы был один броузер — затрат
на разработку меньше. Ну в самом деле — при наличии на рынке бесплатного броузера наличие в OS встроенного движка
как-то не сильно увеличивает привлекательность OS как таковой. По идее они должны сейчас сконцетрироваться на XAML/WPF
— это то что действительно может сделать погоду для Windows — суть принести больше денег.

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

.>c-smile wrote:

>> Можно я еще раз повторю вопрос? Зачем там XM[b]L ?
.>Это спецификация, называется "Binding Language". Он не просто пара хандлеров... А язык описания байндинга.
.>Почитай http://www.w3.org/TR/xbl/ (правда там 2-я версия).
.>Почему это удобнее сделать в виде xml, а не в виде описания объектной модели, которая должна быть настолько
.>универсальна, чтобы удобно ложиться в модели всех ЯП (или хотя бы популярного большинтсва) — вопрос исключительно
.>флеймогонный.

>> Зачем для задачи связки языка A с HTML нужен еще язык B?
.>Ну html тут на самом деле косвенно, тут и xul и прочая радость прикручивается.

Так, давай от "счастья всем и бесплатно" перейдем на реальные задачи:

Чего конкретно тебе не зватает в связке HTML/CSS/Script или если уже хочешь то XUL/CSS/Script для
решения "задачи" binding?

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

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

A>>Это *не* сложно. У меня на освоение ушло не больше часа, при том, что раньше я вообще ничего не знал об XBL.
CS>У меня на освоение понятия JSON ушло 3 секунды — ровно сколько заняло прочтение определения.

А сколько у тебя ушло на изучение JavaScript перед этим? Разница в том, что ты использовал известный тебе язык, а я изучил новый. Да и при чём тут JSON?

A>>Вот знаешь, что мне не нравится в таком подходе? То, что JavaScript влез в CSS файл (prototype), и вообще не очевидно откуда взялся этот Foo.
CS>Напиши:
CS>

CS>div.Foo 
CS>{
CS>  binding: Foo; 
CS>}
CS>

CS>Foo это символическое имя — некий ID. К конкретному языку отношения не имеющий.

Не важно, все равно часть какого-то чужеродного языка.

CS>Любой язык в состоянии выполнить запрос типа:
CS>

CS>  for(var el in $$("*{binding}")) bind(el, el.style.binding, handlers);
CS>

CS>и назначить соотв. handlers всем элементам имеющим описанный binding атрибут в CSS.

А зачем мне делать этот запрос, если всё будет сделано за меня автоматически?

A>>Тут я согласен с . (http://rsdn.ru/Forum/Message.aspx?mid=2394796&only=1

Автор: .
Дата: 05.03.07

), XML позволяет описать данные и поведение, не привязываясь к языку. Т. е. машина получает стандартно описанные имя и аргументы, а уж что там за код за ними, её не интересует.
CS>Абстракция нужна но до определенных пределов. Как я написал выше для того чтобы сделать биндинг нужен 1 (один) атрибут в CSS.
CS>Не нужно городить огород с описаниями функций и их вызовами across language domains, runtimes and different memory allocations schemas.

Так там и есть сейчас один атрибут в CSS.

CS>XBL это технически абсолютно безграмотное решение. Откуда эти идеи вообще все лезут? Кто-нибудь из практиков просил такое придумывать?
CS>Народу в комитетах нужно изображать бурную деятельность как я понимаю...

XBL придумали практики, которые сделали вполне себе работающую платформу Mozilla. Комитет же работает над XBL 2.0, который по-моему вообще сейчас нигде не используется.

CS>И только не надо XUL туда лепить еще. Если XUL использует CSS то он может пользоваться механизмом behaviors точно так же как и HTML.

Почему не надо? Давай уйдём от частностей и будем рассматривать XML, со всеми его XUL, XHTML и прочими.

c-smile wrote:
> A>Это *не* сложно. У меня на освоение ушло не больше часа, при том, что
> раньше я вообще ничего не знал об XBL.
> У меня на освоение понятия JSON ушло 3 секунды — ровно сколько заняло
> прочтение определения.
Угу, а вот придет тебе такой JSON:

[
    "a","b","c",formatDiskD()
]

и что будешь делать?

JSON — это ведь не данные, а КОД.

Значит нам нужен санитайзер для него, который еще будет понимать и
всякие 2*2 и прочие.

В общем, получается не проще XML в итоге.

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

A>Здравствуйте, c-smile, Вы писали:

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

A>>>Это *не* сложно. У меня на освоение ушло не больше часа, при том, что раньше я вообще ничего не знал об XBL.
CS>>У меня на освоение понятия JSON ушло 3 секунды — ровно сколько заняло прочтение определения.

A>А сколько у тебя ушло на изучение JavaScript перед этим? Разница в том, что ты использовал известный тебе язык, а я изучил новый. Да и при чём тут JSON?

Я имею систему функций event handlers в JavaScript. Я также имею систему DOM объектов в JavaScript.

JSON это javascript object notation — способ делкларирования в JavaScript.
Т.е. я могу описать систему bindings средствами JS. Одну из большого набора возможных. Ту которая больше подходит по специфике задачи.

Зачем мне это делать через XBL?

CS>>Foo это символическое имя — некий ID. К конкретному языку отношения не имеющий.

A>Не важно, все равно часть какого-то чужеродного языка.

Я тебя не понимаю. binding: string; с точки зрения CSS это тоже самое что и binding: url(...);
CSS к этому значению никакого отношения не имеет. CSS только наследует этот атрибут и никак еге не интерпретирует.

CS>>Любой язык в состоянии выполнить запрос типа:
CS>>

CS>>  for(var el in $$("*{binding}")) bind(el, el.style.binding, handlers);
CS>>

CS>>и назначить соотв. handlers всем элементам имеющим описанный binding атрибут в CSS.

A>А зачем мне делать этот запрос, если всё будет сделано за меня автоматически?

В Sciter это тоже сделано автоматически. Там кстати подключаются behaviors из двух языков — C++ и script.

Любой UA в состоянии имплементировать то же самое.
Если UA может корректно активировать <a href="#" onclick="something()"> значит он уже знает про Content-Script-Type http header.
Т.е. в состоянии сделать binding "class of elements -> class of event handlers" автоматически.
Способ интерпретации string в атрибуте binding зависит от языка что естественно.

CS>>Абстракция нужна но до определенных пределов. Как я написал выше для того чтобы сделать биндинг нужен 1 (один) атрибут в CSS.
CS>>Не нужно городить огород с описаниями функций и их вызовами across language domains, runtimes and different memory allocations schemas.

A>Так там и есть сейчас один атрибут в CSS.

Ну да только для того чтобы запустить всю эту машинерию тебе нужно послать http request (40k машинных инструкций только локально)
инстанциировать XML парсер, построить XBL DOM, и собственно выполнить element.onclick = some_function_ref.
Потом прикопать распарсенный XBL DOM на случай внезапных UpdatePanels из ASP.NET и прочих динамических DOM манипуляторов.

А потом сесть и погоревать: вот блин хотели thin client соорудить а получилось как всегда.

Ну зачем оно так?
Ну есть же у меня на машине уже все и CSS я уже скачал, DOM — вот он родной, и скрипт уже тоже есть — в нем все что мне нужно уже здесь — все связанное
в систему. Зачем же мне еще эта XBLя нужна?

Можешь привести практический пример когда без XBL ну просто никуда или оно настолько красиво выходит что глаз не оторвать?


CS>>XBL это технически абсолютно безграмотное решение. Откуда эти идеи вообще все лезут? Кто-нибудь из практиков просил такое придумывать?
CS>>Народу в комитетах нужно изображать бурную деятельность как я понимаю...

A>XBL придумали практики, которые сделали вполне себе работающую платформу Mozilla. Комитет же работает над XBL 2.0, который по-моему вообще сейчас нигде не используется.

XBL придумали в Mozilla для чего? Как часть XUL насколько я помню. Ну дык XUL это XML и есть, добавить пару тройку tags туда рояли уже не играет. Т.е. там оно к месту (наверное)
Но зачем выдирать это оттуда и цеплять это к HTML?

CS>>И только не надо XUL туда лепить еще. Если XUL использует CSS то он может пользоваться механизмом behaviors точно так же как и HTML.

A>Почему не надо? Давай уйдём от частностей и будем рассматривать XML, со всеми его XUL, XHTML и прочими.

XML это не HTML. HTML это не XML и никогда им не будет по определению. Тэг <html> optional в HTML. За этим простым фактом много чего стоит.
Если нужно больше на эту тему то читаем www.whatwg.org и мотивацию HTML5.

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

C>c-smile wrote:
>> A>Это *не* сложно. У меня на освоение ушло не больше часа, при том, что
>> раньше я вообще ничего не знал об XBL.
>> У меня на освоение понятия JSON ушло 3 секунды — ровно сколько заняло
>> прочтение определения.
C>Угу, а вот придет тебе такой JSON:
C>

C>[
C>    "a","b","c",formatDiskD()
C>]
C>

C>и что будешь делать?

Это про что?

C>JSON — это ведь не данные, а КОД.

Тебя обманули. См. www.json.org

C>Значит нам нужен санитайзер для него, который еще будет понимать и
C>всякие 2*2 и прочие.

C>В общем, получается не проще XML в итоге.

Это про что вообще?

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

Долго думал и решил всё же ответить

Вернее спросить Ну или всё же ответить, расценивайте как хотите. Всё нижеследующее — только лично моё очень скромное ИМХО.

Что даст JavaScript статическая типизация? Скорость? Так ведь всё равно как ни крути эта скорость не сможет приблизиться даже к скорости Java/.Net приложений, не говоря уже о скорости "битовыжималок" типа С и С++. "Скриптовость" в обозримые N лет не даст возможности написать на JavaScript что-то типа MP3 и/или MP4 encoder, ну или какой-нибудь 3D shooter. Даже на вполне развитых Java/.Net эта задача довольно-таки проблематичная. Существенного прироста производительности от введения статической типизации в JavaScript ждать не приходится — да, на каких-то алгоритмах она вырастет на порядок-два, но проблема в том что такие алгоритмы на данный момент очень мало кто пишет именно на JavaScript.

Далее. Ещё одно преимущество статической типизацией перед динамической — это выявление существенного количества ошибок на этапе компиляции в противовес оному в run-time. Мне кажется что процент ошибок который можно выявить в compile-time за счёт статической типизации — не так уж высок (ну, или по крайней мере — часто переоценивается). Особенно это коснётся JavaScript — ведь его динамическая "сущность" никуда не денется — люди так же будут пихать указатели на функции без всякой их типизации как параметры других функций — уж очень это удобно в JS Определённую аналогию тут можно провести с C и C++ — вроде бы, новомодные фичеры С++ позволяют писать не применяя опасных конструкций С — но ведь сколько времени и усилий понадобилось для того чтобы заставить программистов перелезть с одного стиля написания программ на другой!

Ну и теперь про недостатки такого решения:
A>Получаем как бы 2 уровня языка: простой (то, что имеем сейчас) и продвинутый (статическая типизация и т. п.).
Мне кажется (ещё раз подчеркну — ИМХО) вместо того чтобы иметь язык с двумя уровнями — лучше иметь 2 языка. Потому что человек который пишет скрипты "по старинке" всё равно столкнётся с проблемой понимания нового кода (примерно как программист на С смотрит на код на С++). А человек который пишет скрипты "с типизацией" всё равно рано или поздно постарается весь старый (утиный) код из проекта выкинуть. Уж простите за сравнение, но вспоминается прошлая попытка написать универсальный язык для программистов и домохозяек — Visual Basic. Помнится, что плевались на него с обеих сторон — и домохозяйки, и программисты.

Насчёт того что вместо развития JS стОило бы стандартизировать какую-то виртуальную машину — я скорее согласен чем не согласен. Google SpreadSheet у меня подтормаживает на любом браузере, и есть у меня подозрения что даже с новым JS 2.0 он кардинально быстрее не станет. C другой стороны, для производителей браузеров ИМХО проще сделать чётко специфицированную виртуальную машину чем реализовать довольно сложный язык.

Ну и то, чего мне больше всего жалко в "старом добром" JS — это чистоты концепций. Да, помнится чем-то подобным восхищались на этом сайте в отношении Oberon Но языка с таким простым и, одновременно, как бы так выразится — сбаллансированным, что ли — синтаксисом я ещё не встречал Ну очень всё просто и минималистично. Но при этом можно использовать массу как императивных, так и функциональных паттернов программирования. Очень просто всё, кроме (может быть) концепции конструкторов — тут я согласен с c-smile что это скорее баг дизайна. А как только язык разрастётся — тут же подобные баги дизайна полезут как тараканы на стол с крошками.

В целом всё ИМХО закончилось

Здравствуйте, Cyberax, Вы писали:
C>http://rsdn.ru/File/37054/newrings_cassini_big.jpg
Could not reproduce. Pentuim IV 2.66 Ghz + LCD Monitor Acer AL1715.

C>http://rsdn.ru/File/37054/iebug.png — через минуту браузинга. Причем
C>проявляется не всегда.
Масштаб верни в 100%. IE не смог научиться корректно масштабировать смесь текста с изображениями.

C>Не до такой степени.
То же самое — масштаб верни в 100%.

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

L>Далее. Ещё одно преимущество статической типизацией перед динамической — это выявление существенного количества ошибок на этапе компиляции в противовес оному в run-time. Мне кажется что процент ошибок который можно выявить в compile-time за счёт статической типизации — не так уж высок (ну, или по крайней мере — часто переоценивается).

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

L> Особенно это коснётся JavaScript — ведь его динамическая "сущность" никуда не денется — люди так же будут пихать указатели на функции без всякой их типизации как параметры других функций — уж очень это удобно в JS

А что мешает пихать в качестве параметров типизированные функции.

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

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

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

В дополнение к http://rsdn.ru/Forum/Message.aspx?mid=2396913&amp;only=1

Автор: konsoletyper
Дата: 07.03.07

L>Что даст JavaScript статическая типизация? Скорость? Так ведь всё равно как ни крути эта скорость не сможет приблизиться даже к скорости Java/.Net приложений, не говоря уже о скорости "битовыжималок" типа С и С++. "Скриптовость" в обозримые N лет не даст возможности написать на JavaScript что-то типа MP3 и/или MP4 encoder, ну или какой-нибудь 3D shooter. Даже на вполне развитых Java/.Net эта задача довольно-таки проблематичная. Существенного прироста производительности от введения статической типизации в JavaScript ждать не приходится — да, на каких-то алгоритмах она вырастет на порядок-два, но проблема в том что такие алгоритмы на данный момент очень мало кто пишет именно на JavaScript.

Вот это всё надумано, конечно никто не собирается использовать JavScript для несвойственных ему задач. А шутер на нём и сейчас вполне реально написать, только очень примитивный и тормозной, см., например, http://abrahamjoffe.com.au/ben/canvascape/ и http://abrahamjoffe.com.au/ben/canvascape/textures.htm.

L>Ну и теперь про недостатки такого решения:
A>>Получаем как бы 2 уровня языка: простой (то, что имеем сейчас) и продвинутый (статическая типизация и т. п.).
L>Мне кажется (ещё раз подчеркну — ИМХО) вместо того чтобы иметь язык с двумя уровнями — лучше иметь 2 языка. Потому что человек который пишет скрипты "по старинке" всё равно столкнётся с проблемой понимания нового кода (примерно как программист на С смотрит на код на С++). А человек который пишет скрипты "с типизацией" всё равно рано или поздно постарается весь старый (утиный) код из проекта выкинуть.

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

L>Насчёт того что вместо развития JS стОило бы стандартизировать какую-то виртуальную машину — я скорее согласен чем не согласен.

JavaScript 2 должен будет работать на виртуальной машине. Может она и станет стандартом.

L>>Далее. Ещё одно преимущество статической типизацией перед динамической — это выявление существенного количества ошибок на этапе компиляции в противовес оному в run-time. Мне кажется что процент ошибок который можно выявить в compile-time за счёт статической типизации — не так уж высок (ну, или по крайней мере — часто переоценивается).

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

Если язык — динамически типизирован, но при этом строго типизирован (Erlang ), то особых аргументов в пользу статической типизации не вижу вообще.

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

M>Если язык — динамически типизирован, но при этом строго типизирован (Erlang ), то особых аргументов в пользу статической типизации не вижу вообще.

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

c-smile wrote:

> Чего конкретно тебе не зватает в связке HTML/CSS/Script или если уже
> хочешь то XUL/CSS/Script для решения "задачи" binding?
Надо удобный механизм описания визуальной компоненты. Чтобы по мановению волшебной палочки обычный <input> превращался в
текстовое поле с кнопулькой тута, пимпочкой здеся и финогвинкой тама.
Чтобы можно было в страницу ставить <myns:mimsy>, описав что это за зверь, и использовать.
Короче, что-то похожее на in-place xslt-преобразования, наверно.