Слайды "ECMAScript 6"
 

Слайды с DevConf "ECMAScript > Будущее"

http://www.slideshare.net/dmitrysosh...ript-6-8211902

Положительное будущее :) Хотя не могу сказать, что мне его не хватает. Меня, например, больше интересует, как планируется его воплощать в жизнь. Может быть, предусматривается что-то на подобие feature detection? И ожидается ли статическая типизация и классы?

на прошлой неделе как раз наткнулся на эти слайды, интересно только про Proxy хотелось бы по больше узнать в частности о расширении синтаксических конструкций.
Эта тема меня просто покорила, как я понял Brendan Eich хочет реализовать часть парадигмы из CoffeeScript и Python, за что ему нужно отдать должное т.к. расширение в сторону функционального программирования это большой прогресс для языка.

если уж Brendan Eich считает синтаксис JavaScript морально устаревшим, то нововведения не будут лишними и их не нужно боятся))

Печально, но похоже так же как и сейчас, в этой ветке Brendan Eich говорил, что старый синтаксис тоже сохранится (к примеру если появится arrow syntax, то function никуда не денется, вроде как невозможно избавится, по крайней мере пока).

Тут где-то поднимался этот вопрос, и мне почему-то помнится, что это запланировано в ES7 (Strawman)
Есть такая штука как Traceur для тестирования будущих фишек.
Вообще у меня есть желание написать плагин для браузеров, который бы реализовывал возможности будущих версий. Не с кем проконсультироваться на эту тему((

Кстати вот очень интересный доклад на эту же тему от Brendan Eich'a

PS: константы из ES6 уже сейчас поддерживают все браузеры кроме IE!

const foo = function(a) {
     return a;
};

alert(foo(10));

PS: Дмитрий, какие требования к участникам комитета TC-39? :)

императивного? Ты не ошибся?

я их не боюсь, я их не жду

а я думал, это должно печалить только разработчиков реализаций

вот и я о том же. Если это какой-нибудь новый метод, можно проверить есть ли он и воспользоваться своей реализацией, если нету. Или еще что-нибудь сделать. Если же это синтаксис... надо ждать пока браузеры начнут это поддерживать. Но "начнут это поддерживать" - довольно расплывчатое условие. А так как не очень-то и хотелось, можно расслабиться :)

многие языки поддерживают эту парадигму, но на мой взгляд в JS она как-то "вяло" проявляется. То что мы имеем сейчас в отличии от того же Python, мало похоже на это

Вообще, основная идея звучит как "не ломать Web". В идеале это означает, что старый код должен работать на новых движках.

В реальности же, естественно будут появляться какие-то несовместимые синтаксические конструкции, которые повлекут за собой эту самую "поломку" старого кода. Однако, это то, что Brendan Eich называет "a migration tax" (т.е. амортизация, накладные расходы) -- то, ради чего все-таки можно пожертвовать старым кодом. Это, как правило, очень важные конструкции, которые заслуживают, чтобы "ими можно было поломать web" (какие именно -- можно посмотреть здесь -- http://wiki.ecmascript.org/doku.php?...mony:proposals).

Для этого скорей всего будет введено версионирование (например, не type="text/javascript", а type="application/ecmascript;v=6").

Классы как раз сейчас активно обсуждаются в es-discuss, очень велика вероятность, что они будут -- как сахар над делегацией (такие же классы, как Python и CoffeeScript, которые оба являются прототипными языками).

Насчет статической типизации -- нет, нет активных обсуждений. Но будут типизированные массивы (уже есть) и структурированные типы -- для эффективного использования памяти и быстрого к ней обращения. Типы так же фигурируют в предложении value_proxies, но это тоже пока только обсуждается и не окончательно утверждено. Самих же статических типов на уровне языка -- нет, нет активного обсуждения по этому поводу.

Да, но JS и так уже (еще в ES3) многое взял из Python (оба языка писались в одно время -- в 1995 году). CoffeeScript -- да, очень классный язык, и Brendan (спустя год, после того, как я упомянул его на es-discuss и предложил -> функции) сам увлекся Coffee и уже сам, через год, заговорил о них.

В целом же, -> не новация Coffee, стрелка тесно связана с функциями еще с математики, стрелка -- это тип функции в типизированном лямбда-исчислении, стрелки-функции использутся во многих других языках, которые появились задолго до JavaScript и CoffeeScript -- например, Erlang -- 1986 год, -- кстати, это язык на котором я программирую сейчас на моей основной работе; Haskell тоже стрелки использует для функций. Так что, не нужно бояться стрелок -- они вполне себе ассоциированы с функциями (просто я слышал на Twitter высказывания вроде "как эти символы связаны с функцией вообще?" -- самое интересное -- самым прямым способом ;)).

Абсолютно.

В Opera они просто синоним var.

В JS императивное программирование проявлено достаточно полно (изменяемое состояние, последовательные инструкции и т.д.). Как, впрочем, и часть функционального.

Я просто не понял, где там расширение в сторону фукционального/императивного программирования. Просто синтаксис упростили

А по поводу императивного программирования, по-моему как раз только оно и проявляется. Императивное программирование - это когда ты указываешь последовательность действий и есть состояние. Функциональное программирование - это совсем другой подход к проблеме: ты описываешь как решить задачу, но не указываешь последовательность действий. Я бы сказал, что это императивный язык, заимствующий идеи из функциональных языков.

...

а python разве прототипный?

хм, а coffeescript используется в реальных проектах?

и я тут не так давно натыкался на на письмо Брендана Айка
в котором он говорит о чем-то близком. Но непонятно, о каком раннем связывании идет речь, почему оно не возможно и как это влияет на классы (а может и на статическую типизацию). И кстати, о "замораживании" объектов сейчас речь не идет в контексте классов?

Эм, а в чем сложность? Компилятор ведь имеется.

на первый взгляд ничего, но есть моменты, которые для меня пока не понятны...
в каком смысле?

Ага. Как, по большому счету, и JavaScript -- классовый (в нем возможность классового реюза и классовой генерации проявлена в полной мере). Но помимо возможности программировать в классовом стиле, JS, естественно, в основе -- делегирующий (прототипный) язык, т.е. поддерживающий неклассифицированный (или, что я называю, хаотичный) code reuse. Но, я думаю, здесь смысла нет рассказывать подробно.

Как Python и JS связаны с прототипами и классами можно хорошо видеть на скомпилированном коде класса (справа в примере по ссылке) CoffeeScript.

Поскольку, еще раз, класс -- это не какое-то ключевое слово class в языке, это не возможность объявлять классы этим словом; класс -- это возможность классифицировать (а как это делается -- с ключевым ли словом class или function -- это дело десятое уже). И в JS эта возможность была всегда. Правда, без "сахара". В Python (и Coffee) -- с сахаром. Вот и в JS такой же сахар будет.

Если руки дойдут и время все-таки я выделю, я допишу эту статью (она у меня начата, но так и не закончена). А пока -- эта ссылка возможно будет интересна.

Да, конечно же (поищи по Github). У меня тоже есть небольшой проект -- SchemeOnCoffee (тест online).

Тут речь про старые классы из ES4. Сейчас обсуждаются уже "другие" классы.

По поводу раннего связывания -- да, будет такое, и будет касаться всех binding'ов (переменных/функций/модулей и т.д.). Это означает, что, например, ошибки присваивания неопределенной переменной a = 10 будут ловиться еще на этапе компиляции. Глобальный объект будет удален из списка scope chain. Будет глобальный модуль, куда по-дефолту импортированы все глобальные байндинги. Технически это означает, что нельзя динамически (кроме спец. мета-методов), по случайности, создать, например, глобальную переменную -- только import'ом из какого-нибудь другого модуля (а это значит, что опять это известно на этапе компиляции). Но это длинная тема, парой слов не опишешь.

Если классы будут статическими, то раннее связывание поможет, естественно эффективней выделить память (и привязать this сразу однозначно). Но сейчас про статические классы я не слышал (пока только "сахар" обсуждается). Я вообще против только статических классов. Один из вариантов сахара, который я предлагал -- такой.

Есть такой участник TC-39, Mark Miller (Google). У него все примеры -- с Object.freeze и с const :) Но как отмечал Brendan, встроенные конструкторы/классы JS станут статическими только через его труп :D Нет, пока не говориться, что классы будут замороженными по-дефолту. Но, возможно. Мне бы не хотелось (если будет решаться, я выскажусь против).

Именно к TC-39 -- насколько я понимаю, подача заявки от твоей компании, ну и желательно, чтобы твоя компания была связана с разработкой JS, и была мэйнстримовой компанией по такой разработке :) (например, Mozilla, Google, Apple, Microsoft). Или же, ты в своей компании -- какой-нибудь идеолог-евангелист JS -- типа Крокфорда от Yahoo. Но, как мне сказал Крокфорд, нужно только, чтобы ты представлял компанию, а так -- подавай заявку.

А вот участником es-discuss листа (пассивным/активным) может быть каждый. Именно здесь ведется обсуждение дизайна ES. И ты, если есть что предложить и сказать, можешь это легко сделать. Потом уже, на митингах TC-39, это обсуждается в узком кругу. Но сами идеи, сами предложения -- могут поступать от тебя на es-discuss и вполне (если обоснованы) могут быть приняты в стандарт.

http://habrahabr.ru/blogs/javascript/118669/ я об этом

Меня не устраивает время компиляции:

<script src="http://traceur-compiler.googlecode.com/svn/branches/v0.10/src/traceur.js" type="text/javascript"></script>
<script src="http://traceur-compiler.googlecode.com/svn/branches/v0.10/src/bootstrap.js" type="text/javascript"></script>

<script type="text/traceur">
class Foo {
    new(message) {
        this.message = message;
    }
    method() {
        let element = document.querySelector('body');
        element.innerHTML = this.message;
    }
};

let foo = new Foo('Hello, world!');
foo.method();  
</script>

Херасе :blink:

вообще я имел в виду не экспериментальные проекты, а скорее сайты. И получается, теоретически, если можно компилировать на сервере, не обязательно ждать новый синтаксис. Особенно если есть какая-то штука типа compass watch (отслеживание изменений и автоматическая перекомпиляция).

Презентация впечетлила обилием сахара. Жалко что не ввели тип данных словарей с ключами произвольного типа на уровне языка или стандартной библиотеки. Близкое подобие таблиц из Lua было бы весьма полезной добавкой.

Ecma-262 Editon 6
 

Анонс:

Draft Specification for ES.next (Ecma-262 Editon 6)

Пардон за воскрешение темы.
Как отлаживать программу на Traceur, скомпилированную в JS? Другими словами: у меня появилась ошибка в скомпилированном скрипте, как узнать где она в исходном коде?