Инновационный ECMAScript 4 отвержен, реакционный ECMAScript 3.1 становится главной веткой стандарта следующей версии JavaScript

Право же, я не собирался об этом писать...

Не будет в JavaScript честных классов, останется их симуляция.

Рост ну ты блин как всегда умеешь радовать :) Я так надеялся на ECMA 4 ((( нативно выполнять AS в браузере это мегакуль!

это действительно мудрое решение.
дибилизм ECMA 4, равно как и Action Script 3, очевиден.
меня радует то, что наконец то разработчики это поняли.

До меня не доходит, почему никто не стащит идею у Microsoft Internet Explorer, который подерживает 2 языка, JScript и VBScript, кто придумал что браузер не может пожерживать одновременно JS 1.xx и JS 2.x ?

До меня не доходит, почему никто не стащит идею у Microsoft Internet Explorer, который подерживает 2 языка, JScript и VBScript, кто придумал что браузер не может пожерживать одновременно JS 1.xx и JS 2.x ?

Error #2044: Unhandled securityError:. text=Error #2048: Security sandbox violation: http://bitcast.vimeo.com/vimeo/swf/moogaloop.swf?clip%5Fid=1405511&server=www%2Evimeo%2Ecom&show%5Ftitle=1&show%5Fbyline=1&show%5Fportrait=0&color=ff9933&fullscreen=1 cannot load data from http://www.vimeo.com/moogaloop/load/clip:1405511/embed?ver=4&context=undefined&context_id=undefined.
at com.as3.classes.loader.items::XMLItem()
at com.as3.classes.loader::MassLoader/load()
at com.as3.moogaloop4::Moogaloop/loadXML()
at com.as3.moogaloop4::Moogaloop/onAddedToStage()

@Alexey
Спасибо, но я знаю, не первый год в веб индустрии =). Я говорил не о конкретных языках, я говорил об идее, почему бы не добавить языки в браузеры.

Nirth

Ну тут и так понятно - веб-разработчики не будут использовать новые языки, так как их поддерживают не все браузеры.
Разработчики (некоторых) браузеров не будут добавлять поддержку новых языков, так как их всё равно не используют веб-разработчики.

Порочный круг.

Неужели настало время когда WEB стал самодостаточной средой и всякие инновации только ему мешают?
Как быстро WEB достиг насыщения !!! Стагнация господа,однако !

вот именно, что "всякие".

JS взорвал веб еще лет 10 назад. Произошло это в острой необходимости сделать страницы хоть сколько-нибудь интерактивными, расширить "узость" клиента.

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

Может, это и хорошо, что тормознули новый стандарт. Часто бывает, что прогрессивные вещи опережают потребности и гибнут зазря. Или если не гибнут, то используются совсем в иных целях, чем предполагали разработчики. Вообщем, мораль - дорого яичко к христову дню, как говорила моя бабушка :)

Всё-таки кое в чём должен согласится с index'ом по поводу AS3 и ECMA 4.

При всех своих плюсах, есть и ряд недостатков. Один из них - уменьшение стабильности.
На AS1/2 и ECMA3 даже кривой код зачастую продолжает работать, работать и работать.
Например, что-нибудь типа
obj.field.doSomething()
не вызовет особых проблем, даже если obj == null.

В AS3 же вывалиться exception даже если obj.field == null и остановится выполнение всего остального скрипта, а это куда более заметный конечному пользователю баг.

2Dan
ОК ... :)

@index
А в чем дебилизм ECMA 4, не считая кучи синтаксиса в котором куча семантического мусора a la var, function и тд. Я правда не отказался бы от __resolve еще.

@Dan
Эксепшены юзери без дебаг плеера не видят, и потом они легко обдятся. Бывают моменты когда они мешают, но бывают когда из за них легче найти ошибку, плюс тестеры могут слать стэк трейсы, что заметно облегчает девелоперам их исправление, стэк трейс намного лучше описания – нажмите на кнопку А потом Б потос С и потом заметите там фигню.

Да я прекрасно понимаю, какая на самом деле польза от эксепшеном.
Но иногда от них вред.

Бывают такие ошибки, которые и не ошибки совсем, а просто мелкие недочёты.
Т.е. на AS2 можно было бы и не искать, а на AS3 искать порой приходится.

Допустим, есть у нас что-то типа такого.

for (var i:int=0; i
   items[i].init();

}

startApplication();

И по каким-то причинам один из элементов массива у нас оказался null. Причины могут быть разные: удалили элемент, или брали из внешнего источника и этот элемент был пропущен, или генерировали на основе XML файла и пихали в массив по индексу всятому из атрибута id, и в этих самых id была не очень последовательная нумерация. Вобщем, причины разные.

И возможно, что отсутствие одного элемента само по себе не является критической ошибкой. Ну нет и нет - главное чтобы остальные работали.

В AS2 у нас сработает нормально: элемент null будет спокойно пропущен. Пусть это не красиво с точки зрения чистоты кода, но зато работает.

В AS3 произойдёт эксепшн, прервёт выполнение, startApplication() не будет вызван - в результате юзер (тестер, заказчик, продюсер и прочие) видит чёрный экран. И теперь нам нужно исправлять эту маленькую кривость, которая превратилась в критическую ошибку: вставлять if или try.

Хотя, разумеется, иногда ситуация бывает обратная: когда один эксепшен (и сопутсвующий стек-трейс) позволяет сразу локализовать действительно серьёзную ошибку, которую в AS2 пришлось бы долго и упорно выискивать.

>И по каким-то причинам один из элементов массива у нас оказался nul
if...else вам в руки=)

Так я об этом написал в конце: или if, или try.

И ещё раз повторю свою мысль: в AS2 отсутствие проверки на null - небольшой косячок, который зачастую никак не сказывается на работоспособности.
В AS3 отсутствие проверки на null может привести к падению всего приложения.

А в вебе, с его плюрализмом браузеров, это очень существенно.

Небольшая добавочка...

Простая конструкция типа (пардон, если где-то накосячил, я JS уже хорошенько подзабыл)
alert(window.document.all.images[3].style.display)

может превратиться во что-то такое:

if (window && window.document && window.document.all && window.document.all.images && window.document.all.images[3] && window.document.all.images[3].style) {
   alert(window.document.all.images[3].style.display);
}

Либо в такое:

if (window && (a=window.document) && (b=a.all) && (c=b.images) && (d=c[3]) && (e=d.style)) {
   alert(e.display);
}

Либо (самый простой вариант, пожалуй), в такое:

try {
   alert(window.document.all.images[3].style.display);
} catch (e:Error) {
   // do nothing
}

Но в любом случае - множество лишних строчек, которые очень легко забыть (или просто лень) написать.

>Но в любом случае - множество лишних строчек, которые очень легко забыть (или просто лень) написать.
Если я вам скажу что это исправляется отказом от динамических данных в пользу "строгих" классов, вы скажете что вам лень их писать, и будете по своему правы. Так что я скажу – да да я вас понял, но мне было интересно мнение index'a =)

Переменная "строгого" типа тоже может быть null. Все выше приведённые примеры написаны именно с учётом того, что это могут быть "строгие" классы. В том числе пример с JS - это пример того, как бы это могло выглядеть на ECMA4.

Кроме того, само использование строгих классов и run-time проверки типов может порой вызывать нежелательные эксепшены (хотя AS2 бы схавал и не подавился).

Короче, весь мой флуд одной фразой: в AS3 стабильность принесена в жертву ради простоты отладки.

А мнение index'а по поводу AS3 можно почитать в коментах в топике-предтече: Встречайте ECMAScript4. Обзор нового стандарта сетевого языка
Кстати, там он обещал супер-пупер компилятор. Интересно, в какой он стадии, всё-таки 9 месяцев уже прошло.

>А мнение index'а по поводу AS3 можно почитать в коментах в топике-предтече:
Спасибо.

>Короче, весь мой флуд одной фразой: в AS3 стабильность принесена в жертву ради простоты отладки.
Да да, я вас понял.

Одна из лучших дискуссий на риппере. Спасибо - получил и пользу, и удовольствие!