Комментарии 179
> или использовать функцию bind
forEach() можно задавать контекст:
[10, 20, 30].forEach(function(value, index, array){}, this)
forEach() можно задавать контекст:
[10, 20, 30].forEach(function(value, index, array){}, this)
В библиотеках полно API, где можно передавать контекст. Например, computed properties в Knockout JS:
Другое дело, что в одних библиотеках контекст может передаваться так, в других — иначе. И когда работаешь с несколькими либами сразу, то начинаешь путаться. bind же работает всегда одинаково, так что со временем я на него пересел.
this.fullName = ko.computed(function() {
return this.firstName() + " " + this.lastName();
}, this);
Другое дело, что в одних библиотеках контекст может передаваться так, в других — иначе. И когда работаешь с несколькими либами сразу, то начинаешь путаться. bind же работает всегда одинаково, так что со временем я на него пересел.
forEach() можно задавать контекст:
[10, 20, 30].forEach(function(value, index, array){}, this)
А addEventListener и десятки других, где контекст задавать нельзя?
Конкретно в addEventListener можно задать контекст
Просто приведённый в статье пример с forEach неэффективен, а то, что есть такая функция как bind, должен знать каждый разработчик.
var eventObject = { a: -99 };
document.addEventListener("click", eventObject);
eventObject.handleEvent = function(e){console.log(e.type, e, ++this.a)};
Просто приведённый в статье пример с forEach неэффективен, а то, что есть такая функция как bind, должен знать каждый разработчик.
О! Слона-то я и не приметил: «This must be an object implementing the EventListener interface, or simply a JavaScript function».
Аллилуйя! Славься let!
Славься ли? Необходимости в let нет.
А чем let не устраивает?
Тем, что есть var. Зачем ещё и делающий-почти-то-же-самое let?
Ну вот тут описано, чем var может быть опасен
Там описано, чем пренебрежение чтением документации может быть опасно.
> Pitfall 1
// Все знают, что
function ololo(){
for (var i in array)…
}
// То же самое, что
function ololo(){
var i;
for (i in array)…
}
> Pitfall 2
// 1
for (var i=0; i < (arr.length — 1); i++){
var func = function(i){
return arr[i];
}.bind(null, i);
result.push(func);
}
// 2
for (var i=0; i < (arr.length — 1); i++){
var func = (function(i){
return arr[i];
})(i);
result.push(func);
}
// 3
arr.forEach(function(v){
var func = (function(){
return v;
});
result.push(func);
});
И получается, что let вводят, как защиту от дурака, который может случайно оконфузиться в паре случаев. А ещё дурацкие скобки постоянно приходится закрывать… Надо в ECMA 7 это учесть, ага. :)
> Pitfall 1
// Все знают, что
function ololo(){
for (var i in array)…
}
// То же самое, что
function ololo(){
var i;
for (i in array)…
}
> Pitfall 2
// 1
for (var i=0; i < (arr.length — 1); i++){
var func = function(i){
return arr[i];
}.bind(null, i);
result.push(func);
}
// 2
for (var i=0; i < (arr.length — 1); i++){
var func = (function(i){
return arr[i];
})(i);
result.push(func);
}
// 3
arr.forEach(function(v){
var func = (function(){
return v;
});
result.push(func);
});
И получается, что let вводят, как защиту от дурака, который может случайно оконфузиться в паре случаев. А ещё дурацкие скобки постоянно приходится закрывать… Надо в ECMA 7 это учесть, ага. :)
Дык надо просто вар сделать как лет хотят.
Тогда в старых скриптах возможно появление неожиданных ошибок, приводящих к самым разным глюкам.
Хорошей практикой чуть позже станет использование let повсеместно, вот и все.
Хорошей практикой чуть позже станет использование let повсеместно, вот и все.
Я считаю, что разработчикам ecmascript давно пора забить на старые скрипты и сделать всё по уму, как когда-то это сделала Adobe.
Тогда в старых скриптах возможно появление неожиданных ошибок
Оно не просто возможно, а очень даже вероятно, и такая вероятность приближалась бы к 100%. И все же появление в коде let наряду c var несколько усложнит понимание этого кода, пожалуй
Выходит новый стандарт и нужен новый контракт. Пусть скажем контейнер будет, что то
script type=«text/javascript» language=«javascript» version=«6.0»
в случае ошибки искать и думать как обойти, но не выдумывать как сделать совпадение контрактов в разных версиях — все равно ни к чему это не приводит смотрите хотя бы расширение интерфейсов SQL в Java. Просто не нерабочий код и и все…
script type=«text/javascript» language=«javascript» version=«6.0»
в случае ошибки искать и думать как обойти, но не выдумывать как сделать совпадение контрактов в разных версиях — все равно ни к чему это не приводит смотрите хотя бы расширение интерфейсов SQL в Java. Просто не нерабочий код и и все…
Уже ответили.
не надо. очень «весело» внутри catch-блока не меть доступа к переменным объявленным в try. а после for-in не иметь возможности узнать, что тело ни разу выполнено не было. var + короткие функции = куда более практично.
Почему-то в других языках таких проблем нет.
не надо. очень «весело» внутри catch-блока не меть доступа к переменным объявленным в try. а после for-in не иметь возможности узнать, что тело ни разу выполнено не было. var + короткие функции = куда более практично.Объявлять необходимые переменные на необходимом уровне? Например:
// Было
try {
let foo = fail();
} catch (e) {
// foo
}
// Стало
let foo;
try {
foo = fail();
} catch (e) {
// foo!
}
Не было бы, если бы var работал как let.
А что насчет хвостовой рекурсии?
Похоже, будет
Что еще для счастья надо? Currying
Function.prototype.bind, чем-то не устраивает — свое пишется в несколько строчек.
Частичное применение функции и карринг это разные вещи
.bind — не каррирование, но, повторяю, чем-то не устраивает — каррирование пишется в несколько строчек — кол-во ожидаемых аргументов у функции в length и функции высшего порядка никто не отменял.
Простите, а таки чем bind не карирование?
Разница в понятиях — частичное применение задает один параметр из N и возвращает функцию от (N-1) параметра. Каррирование — разложение функции от N аргументов на последовательность из N функций от 1 аргумента каждая:
Или как-то так :)
var f = function(x, y, z) {
console.log([x, y, z]);
};
// Частичное применение
var g = f.bind(null, 54);
g(2, 3); // => [54, 2, 3]
// Карринг
var h = function(x) {
return function(y) {
return function(z) {
f(x, y, z);
};
};
};
h(10)(20)(30); // => [10, 20, 30]
Или как-то так :)
А какой тогда практический смысл в карринге?
Function.prototype.curry=function(){
var fn=this,args=[];
return function cur(){
args.push.apply(args,arguments);
return fn.length>args.length?cur:fn.apply(this,args)
}
}
Function.prototype.part=function(){
var fn=this,args=[].slice.call(arguments);
return function(){
args.push.apply(args,arguments);
return fn.apply(this,args)
}
}
function fn(a,b,c,d){console.log(a+b+c+d)}
// каррирование
fn.curry()(1)(2,3)(4) // 10
// частичное применение (без смены контекста)
fn.part(1).part(2,3)(4) // 10
// .bind
fn.bind(null,1).bind(null,2,3)(4) // 10
В js практического смысла в каррировании, в отличии от частичного применения, тоже не вижу.
А в других языках в чём смысл?
Вопрос не ко мне — активно языки с более продвинутой функциональщиной не использовал, может там смысл и есть.
Вот пример с каррированием в Ruby:
Этот же код без каррирования:
То есть в этом случае каррирование — синтаксический сахар для создания замыкания.
def parse(enum)
processor = MetadataProcessor.new
reader = ->(dir_path) {processor.read_metadata dir_path}
saver = ->(metadata) {processor.save_metadata metadata if metadata}
loop do
EM.run_block do
enum.portion.each do |dir_path|
# EventMachine вызывает первый коллбэк без параметров,
# поэтому необходимо обернуть лямбду с параметром в замыкание.
EM.defer(reader.carry(dir_path), saver)
end
end
end
end
Этот же код без каррирования:
def parse(enum)
processor = MetadataProcessor.new
reader = ->(dir_path) {processor.read_metadata dir_path}
saver = ->(metadata) {processor.save_metadata metadata if metadata}
loop do
EM.run_block do
enum.each do |dir_path|
# EventMachine вызывает первый коллбэк без параметров,
# поэтому необходимо обернуть лямбду с параметром в замыкание.
reader_closure = ->() {reader.(dir_path)}
EM.defer(reader_closure, saver)
end
end
end
end
То есть в этом случае каррирование — синтаксический сахар для создания замыкания.
В целом, это удобный элемент чисто функционального программирования — в той же Scala каррирование реализовано на уровне синтаксиса языка.
Я могу ошибаться, но мне кажется что каррирование — это вырожденный случай частичного применения функций или, по крайней мере, может легко через него выражаться. Адепты функционального программирования, поправьте меня :)
Я могу ошибаться, но мне кажется что каррирование — это вырожденный случай частичного применения функций или, по крайней мере, может легко через него выражаться. Адепты функционального программирования, поправьте меня :)
Переработал, забыл массивы аргументов скопировать, но сути не меняет:)
На вскидку github.com/monolithed/Tuples
Неплохой обзор, но сильно уж краткий — например, про yield (как по мне — одна из основных фишек ES6) — одна строчка, хотя Аксель довольно неплохо тему на квартирнике раскрыл. Про Proxy — вообще ни слова. Про rest и spread ничего…
К сожалению, не был на квартирнике. Если организаторы выложат видео с него, дополню статью
Более того, yield уже есть в FF и принят к разработке в Chrome. Вот и пример хороший есть его использования taskjs.org/
Вот rest и spread действительно нужно добавить в статью, как мне кажется, полезная вещь.
Уже хочу!
«Мы долго пытались навязать мнение, что вам не нужны классы, импорты, блочная область видимость, и часть адептов даже поверила в это на уровне религии. Они убеждали остальных, что в JS есть „классы“, что там всё намного круче, потому что код „можно лепить самому“. А потом мы решили сделать всё, как положено.»
Классы в новом стандарте — синтаксический сахар для прототипов.
А с let просто пошли на поводу. Ещё теплится надежда, что let отменят.
А с let просто пошли на поводу. Ещё теплится надежда, что let отменят.
Да, я в курсе про классы. Но может хотя бы это хоть немного отвадит людей каждый чих описывать в либах и фреймворках.
Чем вам let мешает? Вас заставляют им пользоваться? Или все же вопрос религии?
Let в драфтовом стандарте с 2011 года (12.2.1 Let and Const Declarations).
Возможно вы не понимаете всей мощи let?
Решение:
Теперь с let:
Возможно вы не понимаете всей мощи let?
var array = [];
var i = 10;
while (i--) {
array.push(function() {
return i;
});
}
array[0](); // -1
array[1](); // -1
//... -1
Решение:
var array = [];
var i = 10;
while (i--) {
array.push(function(i) {
return function() {
return i;
};
}(i));
}
array[0](); // 9
array[1](); // 8
// ...
Теперь с let:
var array = [];
var i = 10;
while (i--) {
let conter = i;
array.push(function() {
return conter;
});
}
array[0](); // 9
array[1](); // 8
// ...
Решение посимпатишнее
array.push(function(i){
return i;
}.bind(null, i));
Или использовать forEach (http://habrahabr.ru/post/175371/#comment_6098047).
Я ведь не дурак и знаю JS — его в моей жизни, хоть попой ешь: серверный и клиентский JS, AS, Haxe и даже VBScript. :)
array.push(function(i){
return i;
}.bind(null, i));
Или использовать forEach (http://habrahabr.ru/post/175371/#comment_6098047).
Я ведь не дурак и знаю JS — его в моей жизни, хоть попой ешь: серверный и клиентский JS, AS, Haxe и даже VBScript. :)
Проблема на самом деле немного глубже, а именно в смешивании функциональной и императивной парадигм, замыканий и мутабельных переменных. Каждый выкручивается как может. В python, например, используется хак
lambda i = i: <текст функции>, в С++ — точными указаниями что и как замыкать.
Непонятный гибрид функционального и «типа ООП» языка. Должен быть понятным для тех, кто, скажем так, «не программист» и одновременно приемлем для остальных. Короче, я думаю, что было бы неплохо уже определиться, в какую сторону двигаться — либо понятности, либо удобности.
А вы считаете понятности с удобностью не по пути?
Ну если брать функциональное программирование, то таки да — оно не сразу понятно. ООП более очевидный. Так что да, в данном случае им не по пути :)
Не согласен. Объяснить гипотетическому программисту который умеет программировать исключительно на Лиспе как работает ООП в C++ будет значетельно сложнее чем обучить С++ программиста писать на Лиспе. Очевидность ООП состоит только в том что это по сути общепринятый стандарт на сегодняшний день. А совместить ООП с функциональщиной, да еще и так чтобы было удобно и понятно — вполне возможно. Scala тому пример.
Не знаю, мне кажется, что плохо мешать парадигмы. Раз уж изначально решили делать JavaScript функциональным (а ведь так и есть), то пусть он таковым и будет.
Вы что выдумываете? JS с дня номер раз ООП. Или вы ещё не различаете классовое ООП и прототипное?
Не знаю, мне кажется, что плохо мешать парадигмы
Наоборот, это очень хорошо. Весь кайф в JS в том, что можно паралельно писать в двух парадигмах.
А теперь давайте вспомним про общеизвестный C++. Как вы думаете, сколько парадигм переплетено в его стандарте?
Насчет лиспа не согласен, на лиспе ООП очень легко реализуется с помощью макросов. Lisp не удачный пример, хорошего Lisp программиста будет легко обучить любому языку. :)
Наверное единственное чего мне действительно сейчас не хватает, так это лямбды подобные C#.
Ага вместе с generics =)
А между тем, можно так
А между тем, можно так
function(x) x * x
Не очень понял вашу строку кода. Поясните?
developer.mozilla.org/en-US/docs/JavaScript/New_in_JavaScript/1.8
Раздел Expression closures
Раздел Expression closures
Но со стрелочкой конечно лаконичнее.
Судя по нововведениям, почему-то показалось, что MS не последнюю скрипку играет в TC39.
Не совсем понимаю, зачем нужны именованные параметры функций в JS. Может кто-нибудь обьяснить?
Для того же что и во всех языках — улучшения читабельности кода. А в чем проблема-то?
JSON же. Зачем его во что-то ещё оборачивать?
Если вы посмотрите внимательнее, увидите что это просто разбор переданных объектов. Если функция объявлена как split(sep=" ", count=0), ее по прежнему нельзя будет вызвать split(count=5).
В других языках именованные параметры используются для того, чтобы не запоминать их порядок, чтобы они были опциональны и чтобы можно было добавить новые в функцию не поломав старый код. В JS с этим справляется JSON. В чем смысл? Просто как сахар над JSON?
Да, сахар. Почему бы нет. Только не JSON, а хеш.
Пожалуйста, не говорите, что в js используется json, это тавтология. Json — это «запись объектов как в js». И в других языках тоже объекты как-то записываются. Тем не менее в них есть именованные параметры. Потому что передача объекта и именованные параметры — не одно и то же. И то, что предлагается сейчас в ecma6 — просто сахар для объектов, да.
Ок, про сахар понял. Вобщем, почти ничего кроме сахара не добавили. Печально.
Не каждый валидный объект в js будет валидным объектом json. Но любой json будет валидным js объектом. Думаю различие уместно
Нет, не любой (: Строки обрабатываются по-разному.
А приведите, пожалуйста, пример. Кроме того, прошу заметить, что я не говорил, что JSON декларация и литерал объекта в JS будут идентичными.
С википедии вкратце:
Despite the widespread belief that JSON is a JavaScript subset, this is not the case. Specifically, JSON allows the Unicode line terminators U+2028 line separator and U+2029 paragraph separator to appear unescaped in quoted strings, while JavaScript does not.[9] This is a consequence of JSON disallowing only «control characters». This subtlety is important when generating JSONP.
Despite the widespread belief that JSON is a JavaScript subset, this is not the case. Specifically, JSON allows the Unicode line terminators U+2028 line separator and U+2029 paragraph separator to appear unescaped in quoted strings, while JavaScript does not.[9] This is a consequence of JSON disallowing only «control characters». This subtlety is important when generating JSONP.
Как всегда, много плюсов но немало и минусов.
Из минусов:
Почему нельзя имплементировать полноценный Pattern Matching Вместо сложнозапоминаемых принципов типа «Destructuring assignment»?
Синтаксис именованния аргументов функций перегружен лишней парой скобок.
Главный вин для меня — сахар для анонимных функций. Для языка где активно применяются колбеки — это маст хэв.
Из минусов:
Почему нельзя имплементировать полноценный Pattern Matching Вместо сложнозапоминаемых принципов типа «Destructuring assignment»?
Синтаксис именованния аргументов функций перегружен лишней парой скобок.
Главный вин для меня — сахар для анонимных функций. Для языка где активно применяются колбеки — это маст хэв.
Destructuring assignment
--видимо, потому что давно отработаны в Мозилле
Синтаксис именованния аргументов функций перегружен лишней парой скобок.
--а это потому что они решили совместить позиционные и именованные аргументы
вин — да, мастхев, ибо коллбеки, куул, окей. Но почему-то они не сделали эквивалентными два синтаксиса.
--видимо, потому что давно отработаны в Мозилле
Синтаксис именованния аргументов функций перегружен лишней парой скобок.
--а это потому что они решили совместить позиционные и именованные аргументы
вин — да, мастхев, ибо коллбеки, куул, окей. Но почему-то они не сделали эквивалентными два синтаксиса.
>Именованные параметры функций
Судя по синтаксису, литералы объектов теперь передавать нельзя?
Судя по синтаксису, литералы объектов теперь передавать нельзя?
Отлично. Правда сделали бы лет 5-6 назад эти изменения, может быть и не нужен был бы CoffeeScript :)
И тем не менее, количество сахара в кофи превосходит новую ECMA… я даже затрудняюсь предположить, во сколько раз.
Иногда слишком сладко — тоже плохо. Я вот смотрю на ES6 и понимаю, что это как раз то, что надо. Уже просто не могу дождаться.
Зачем ждать? Вроде ж уже есть компиляторы ES6. Даже с поддержкой Source Maps.
А поддержка IDE?
Для Sublime вроде что-то было. Но не юзал, к сожалению, нет возможности.
вроде что-то было
Что-то вроде — это не достаточно.
Да и текстовый редактор — не айс, я к WebStorm привык. Жду, когда в нём появится.
Да, согласен, Sublime дело вкуса.
Сходу нагуглил. Хотя опять же, не имел с этим дело, мало ли что там написано )))
Сходу нагуглил. Хотя опять же, не имел с этим дело, мало ли что там написано )))
зачем это все? js, как язык, коряв от рождения, но он популярен благодаря постоянству и как следствие — выдающейся совместимости. новые навороты, не несут ни чего оригинального — все это есть в нормальных языках и даже больше — но сводят все преимущества js на нет.
Smells like Ruby.
Спасибо за шикарный обзор и шикарную новость! Славься JavaScript :)
Ура! Классы же!
Это синтаксический сахар, под капотом там прототип.
Это ясно. Но это скорее хорошо, чем плохо. Порог входа заметно упал. Я когда только начинал разбираться никак не мог понять модель ООП с прототипами. Теперь новичкам будет проще.
Да, для этого все и создается. Сейчас нелюбовь к JS только из-за непонимания особенностей. С классами все проще.
Тем, что можно про прототипы изначально вообще не думать. Есть класс, у класса есть методы. Этого достаточно, чтобы начать.
Конечно прийдется. Тут смысл в том, что новичку проще сначала увидеть то, что он уже знает в языке и разобраться в чем отличия от других языков. А уже затем познавать особенности языка, вроде прототипов. Когда начинаешь изучать язык, и нет ничего знакомого — очень сложно начать. Просто не понятно с чего.
В функциях добавилась возможность объявлять у параметров значения по умолчанию
Ура! Прощай экстенд в конструкторах!
Что там с for-of для объектов?
А то в Firefox & Co только вот такое работает:
Но удобный for each...in все равно хотят убрать. :(
А то в Firefox & Co только вот такое работает:
for (var [, value] of Iterator(obj))
Но удобный for each...in все равно хотят убрать. :(
ECMAScript — это официальный стандарт языка JavaScript
ECMAScript — это язык программирования, а стандарт это ECMA-262!
ECMAScript стандартов много. Самый популярный из них — ECMA-262.
Стандарт один, редакций редакций четыре (не считая драфт).
Однако если вы все-таки имели ввиду ECMA-*, то не забывайте C# (ECMA-334)!
Предыдущие версии стандарта ECMA-262 были: ECMAScript 3, ECMAScript 4
Да ладно?
ECMA-262 1st edition,
ECMA-262 2nd edition
ECMA-262 3rd edition
ECMA-262 5th edition
Ну и на вскидку:
ECMA-262 6th edition
ECMAScript 6 (кодовое имя ECMAScript.next) .
Следовало бы разьяснить чем отличается Harmony от ECMAScript.next:
Как сказал Brendan Eich: «ES.next (the first Harmony-era JS standard)»
Так как планы по реализации Harmony были очень амбиционзными и часто пересекались с Strawman, было решено разделить разработу на две рабочии группы ECMAScript.next и Harmony.
Первая группа сосредоточилась на ближайшем релизе ES6, а вторая, по прежнему остается эксперементальной.
должен утвердиться до конца 2013 года
Откуда такая информация?
В текущей версии JavaScript присутствует функциональная область видимости
Вам следует ознакомиться с разделом 10.2 Lexical Environments специкации
Также следовало бы упомянуть о том что некоторые вещи из ES6 уже доступны в FF и Chrome, а также существет несколько полифилов, один из них мой
Ссылки к прочтению:
http://wiki.ecmascript.org/doku.php?id=harmony:proposals
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
> ECMAScript — это язык программирования, а стандарт это ECMA-262!
Ну тогда ECMAScript — это семейство стандартов с различными редакциями. Есть, например, еще ECMA-357 — ECMAScript for XML
> Да ладно?
Я просто не весь список написал
> Откуда такая информация?
Из того же блога. Кроме того Аксел перед аудиторией в полтысячи человек обещал, что стандарт будет принят до конца этого года
Ну тогда ECMAScript — это семейство стандартов с различными редакциями. Есть, например, еще ECMA-357 — ECMAScript for XML
> Да ладно?
Я просто не весь список написал
> Откуда такая информация?
Из того же блога. Кроме того Аксел перед аудиторией в полтысячи человек обещал, что стандарт будет принят до конца этого года
Стандарт один
Есть стандарт ISO, возможно еще какие-то.
Откуда такая информация?
Из интернета, сами ребята из TC39 неоднократно об этом говорили, по крайней мере в мейлинг-листе. В последнее время, правда, все чаще звучат 2 даты:
— конец 2013 — feature freeze
— конец 2014 — финальная редакция.
Блин, как долго ждать(
— конец 2013 — feature freeze
Есть инфа по этому поводу?
Так фичи заморозили. Все новое идет в proposals ECMAScript 7+, а по 6 доводят что есть. С января месяца из изменений внесено разве что:
> Возможность передачи нескольких объектов-источников в Object.assign
> Добавлен итератор для arguments (спрашивается, зачем, если в ES6 arguments не рекомендуется использовать?)
> Установлены одинаковые аргументы map-коллбэка Array.from как для итерируемых, так и для array-like объектов
> Возможность передачи нескольких объектов-источников в Object.assign
> Добавлен итератор для arguments (спрашивается, зачем, если в ES6 arguments не рекомендуется использовать?)
> Установлены одинаковые аргументы map-коллбэка Array.from как для итерируемых, так и для array-like объектов
— конец 2014 — финальная редакция
А по этому поводу как прогресс?
Самому интересно.
Может где более конкретно и проскакивала, но не видел. На свежих на выступлениях членов TC39 — тот же конец 2014. В заметках по последнему собранию проскочила такая фраза, правда она выдрана из контекста:
Может где более конкретно и проскакивала, но не видел. На свежих на выступлениях членов TC39 — тот же конец 2014. В заметках по последнему собранию проскочила такая фраза, правда она выдрана из контекста:
September is the end, otherwise we risk delaying for another 6 months. The final reviewing needs to be done between now and July.
Тоже хороший. Есть уже 24 драфт, и по релизнотам там только фиксы шероховатостей. И так уже последние месяца 3-4. Можно смело читать-изучать.
А браузерьі как прогресс?
Вот: kangax.github.io/compat-table/es6/
Только не обольщайтесь насчет Proxy API в Firefox — там старый вариант.
Из любопытного: Map, Set и WeakMap есть в IE11.
Только не обольщайтесь насчет Proxy API в Firefox — там старый вариант.
Из любопытного: Map, Set и WeakMap есть в IE11.
Ну прокси такой штукой можно поправить. Правда все равно пока разве что играться с ними стоит…
Шо ж за халепа то с Хромом? Ни деструктивного присваивания, ни классов, ни реста, ни стрелочньіх функций, ни итераторов, ни фор-оф =(( Я решил, что когда актуальньіе версии Фокса и Хрома будут на Екма6 — перейду на него, а для старья буду использовать транслятор, но браузерьі что-то пока вообще не спешат.
пс. Прокси не интересна, т.к. слишком сложна, боюсь будет слаба в плане оптимизаций и плохо поддерживаться средами и тяжко ходить дебагером.
пс. Прокси не интересна, т.к. слишком сложна, боюсь будет слаба в плане оптимизаций и плохо поддерживаться средами и тяжко ходить дебагером.
В WeakMap в IE11 в качестве ключа нельзя frozen-объекты использовать
В Firefox все нормально.
Пример
var w = new WeakMap;
// Try to insert freezed object
var obj = {foo: 42};
Object.freeze(obj);
// -- Check
obj.bar = 101;
console.log(obj.bar); // undefined
// -- Insert to WeakMap
w.set(obj, 'baz');
console.log(w.get(obj)); // !!! undefined
// Try to insert regular extensible object
obj = {foo: 42};
// -- Check
obj.bar = 101;
console.log(obj.bar); // 101
// -- Try to insert to WeakMap
w.set(obj, 'baz');
console.log(w.get(obj)); // "baz"
В Firefox все нормально.
Вот рассказал бы кто — будет возможность создания кастомных итераторов? Я имею ввиду не генераторы, а произвольные объекты которые можно передавать в оператор for..of.
Сейчас в Фаерфоксе такое можно делать, определяя у объекта метод "@@ iterator" (т.е. внутреннее имя этого метода в спецификации), но обязательность этой возможности вроде бы не задекларирована. Знает ли кто-нибудь об этой возможности?
Сейчас в Фаерфоксе такое можно делать, определяя у объекта метод "@@ iterator" (т.е. внутреннее имя этого метода в спецификации), но обязательность этой возможности вроде бы не задекларирована. Знает ли кто-нибудь об этой возможности?
Про yield — V8 JavaScript Engine Issue 2355: Implement generators принято на Status: Accepted
неслабенькое расширение…
… В ECMAScript 6 появятся классы…
… В JavaScript наконец-то появятся модули…
Расплакался от счастья…
Синхронный require? В событийно-ориентированном языке? В условиях, когда браузер не может дальше разбирать ДОМ-дерево, пока не выполнен скрипт? Вы смеётесь что ли?
> ECMAScript 6 позволит деструктуризировать при присваивании:
У Фленагана это называлось присваивание с разложением, если мне память не изменяет (в русском варианте книги, ок)
У Фленагана это называлось присваивание с разложением, если мне память не изменяет (в русском варианте книги, ок)
А есть уже реализации? Или пока только стандарты?
очень крутой
От появления require() в ES6 нетрудно прийти в ужас.
Потому что в Node.js этот оператор ужé существует и означает нечто другое.
Да и в RequireJS этот оператор также существует и означает нечто другое.
Обратная несовместимость грядёт.
От такой новости волосы дыбом должны стать на голове!
Потому что в Node.js этот оператор ужé существует и означает нечто другое.
Да и в RequireJS этот оператор также существует и означает нечто другое.
Обратная несовместимость грядёт.
От такой новости волосы дыбом должны стать на голове!
Это не оператор, а функция.
Судя по синтаксису, require работает практически также как в ноде (вопросы вызывают только правила записи идентификатора модуля при загрузке из файловой системы), а import просто выкладывает в глобальную область видимости части загруженного «модуля» (судя по всему, обычного JS-объекта).
RequireJS никто не мешает перекрыть эту функцию по собственному усмотрению и использовать внутри себя оригинал, например.
В общем, введение модулей в таком стиле нанесет минимум повреждений существующим подходам. Да, возможно что-то придется поправить по-мелочи, но про «волосы дыбом» — это перебор )
Судя по синтаксису, require работает практически также как в ноде (вопросы вызывают только правила записи идентификатора модуля при загрузке из файловой системы), а import просто выкладывает в глобальную область видимости части загруженного «модуля» (судя по всему, обычного JS-объекта).
RequireJS никто не мешает перекрыть эту функцию по собственному усмотрению и использовать внутри себя оригинал, например.
В общем, введение модулей в таком стиле нанесет минимум повреждений существующим подходам. Да, возможно что-то придется поправить по-мелочи, но про «волосы дыбом» — это перебор )
Поясню здесь, что термин «оператор» я употребил в значении из вон той статьи, означающем скорее «инструкция», нежели «операция». В этом значении функция — частный случай оператора.
Если можно будет require() перекрыть, тогда ещё слава Богу.
Если можно будет require() перекрыть, тогда ещё слава Богу.
По поводу require() это верно подмечено (Node.JS community негодуэ).
И еще есть ряд вопросов по именованным параметрам функций, меня например вводит в ступор
когда я пытаюсь понять, что то что я вижу, это не то что есть на само деле.
{ } в самой основе языка — литеральное описание анонимного объекта(до присвоения конечно)
А в данном случае как понимать, то что заключено в { }
Что я в итоге в теле foo получу, переданное в { } перекочуют как поля в this, а если у меня подразумевается вложенность в объекте, аля
мне это как описывать?
И еще есть ряд вопросов по именованным параметрам функций, меня например вводит в ступор
function foo({ from, to = 10 }) {
...
}
когда я пытаюсь понять, что то что я вижу, это не то что есть на само деле.
{ } в самой основе языка — литеральное описание анонимного объекта(до присвоения конечно)
А в данном случае как понимать, то что заключено в { }
Что я в итоге в теле foo получу, переданное в { } перекочуют как поля в this, а если у меня подразумевается вложенность в объекте, аля
function foo({ from, to = 10 }) {
...
}
foo({ from: {bar:2, foo: 3}, to: 5 });
мне это как описывать?
Очень радует аккуратный подход к введению новых фич.
В harmony местами такое предлагают, что за судьбу JS страшно становится.
Рад, что в итоге добавляется только самое лучшее и продуманное.
В harmony местами такое предлагают, что за судьбу JS страшно становится.
Рад, что в итоге добавляется только самое лучшее и продуманное.
Есть пара вопросов:
— А модули — не сахар к чему то существующему? Настоящие «модули»?
— И что значит «подгружать из веба»? По спецификации в самом языке какое то встроенное (кроссбраузерное, стандартизированное) средство будет для обращения к удаленному хосту?
Немного пугает еще ожидаемая заморочка с require(), как выше уже упомянул Mithgol.
И интересно, почему arrow-функции не могли назвать более привычным именем «lambda-function» :)
— А модули — не сахар к чему то существующему? Настоящие «модули»?
— И что значит «подгружать из веба»? По спецификации в самом языке какое то встроенное (кроссбраузерное, стандартизированное) средство будет для обращения к удаленному хосту?
Немного пугает еще ожидаемая заморочка с require(), как выше уже упомянул Mithgol.
И интересно, почему arrow-функции не могли назвать более привычным именем «lambda-function» :)
>> А модули — не сахар к чему то существующему? Настоящие «модули»?
Скорее сахар. Например, пример с Math можно было бы реализовать с помощью обычного JavaScript объекта и анонимной функции:
>> И что значит «подгружать из веба»? По спецификации в самом языке какое то встроенное (кроссбраузерное, стандартизированное) средство будет для обращения к удаленному хосту?
Скорее всего, будет какая-то верхнеуровневая спецификация на загрузчики модулей. А уже индивидуальные реализации ECMAScript будут сами решать, как имплементировать эту спецификацию.
>> И интересно, почему arrow-функции не могли назвать более привычным именем «lambda-function»
Потому что технически
Скорее сахар. Например, пример с Math можно было бы реализовать с помощью обычного JavaScript объекта и анонимной функции:
// Math.js
var Math = {};
Math.sum = function sum(x, y) {
return x + y;
}
Math.pi = 3.141593;
(function() {
// Не видна снаружи
function internal() {
...
}
})();
>> И что значит «подгружать из веба»? По спецификации в самом языке какое то встроенное (кроссбраузерное, стандартизированное) средство будет для обращения к удаленному хосту?
Скорее всего, будет какая-то верхнеуровневая спецификация на загрузчики модулей. А уже индивидуальные реализации ECMAScript будут сами решать, как имплементировать эту спецификацию.
>> И интересно, почему arrow-функции не могли назвать более привычным именем «lambda-function»
Потому что технически
function() { return 100 } — это тоже лямбда-функция. А () => 100 — это новая форма записи. И ей нужно было дать какое-то более конкретное названиеЧтобы не читать всё — может тезисно рассказали бы суть?
Забавно. Ну не знаю. По-моему всё это пришло исторически и логически.
rest — это те же arguments, но с учтёнными ошибками.
let уже давным давно в фоксе есть, я бы не сказал, что это что-то новенькое.
значение параметров по-умолчанию — это тоже от такого паттерна:
for-of, сокращённое написание лямбды, модули — это всё не просто «перетянуто из других языков». Это всё реально используемые каждый день вещи, которых очень не хватает в JS.
Я вот читаю топик и понимаю, что буду использовать просто всё, что в нём описано.
Конечно, новичкам оно врядли понадобится
rest — это те же arguments, но с учтёнными ошибками.
let уже давным давно в фоксе есть, я бы не сказал, что это что-то новенькое.
значение параметров по-умолчанию — это тоже от такого паттерна:
function (a) {
if (a == null) a = 1;
}
for-of, сокращённое написание лямбды, модули — это всё не просто «перетянуто из других языков». Это всё реально используемые каждый день вещи, которых очень не хватает в JS.
Я вот читаю топик и понимаю, что буду использовать просто всё, что в нём описано.
Конечно, новичкам оно врядли понадобится
Да, я для себя, когда прочитал, выписал именно тезисами, чтобы потом оценить, что отметили здесь, а что нет. Получилось:
ES6 habrahabr.ru/post/175371/
ES6 habrahabr.ru/post/175371/
* let — блочная область видимости (блок — фигурные скобки)
* аргументы по умолчанию (сахар)
* именованные аргументы (очень похоже на 1 хеш вмеесто ряда аргументов; оформлено как кругло-фигурные скобки ({...}) и комбинируется с позиционными аргументами)
* деструктуризация при присваивании (массивы и хеши), чувствительные и нечувствительные к ошибкам (оператор "?=")
* обёртка классов
* модули — require, import, вместо with
* for-of для собственных свойств
* yield
* стрелочные функции; неточное соответствие: не конструкторы, без this, без arguments
* .bind(): (x, y) => x + y + this.z === function (x, y) { return x + y + this.z }.bind(this)
Новую версию JavaScript уже можно сравнивать с JScript 10.0 от Майкрософт.
Не знаете — есть какие интересные новости по теме?
__proto__ вроде как опять убирают из обязательной секции стандарта и переводят в дополнение, оставляют Object.getPrototypeOf и Object.setPrototypeOf.
Кстати, я тут посмотрел traceur-compiler: traceur-compiler.googlecode.com/git/demo/repl.html
это штукенция, которая делает из Ecma6 кода Ecma3 код. Он реально дохрена уже умеет. Не то, что полгода назад. Слегка грязноваты классы, не поддерживает let и модули, но for-of, => функции, классы, деструктуризацию, значения по-умолчанию — всё это уже работает. К концу года, к фризу, думаю, будут уже практически работающий код.
это штукенция, которая делает из Ecma6 кода Ecma3 код. Он реально дохрена уже умеет. Не то, что полгода назад. Слегка грязноваты классы, не поддерживает let и модули, но for-of, => функции, классы, деструктуризацию, значения по-умолчанию — всё это уже работает. К концу года, к фризу, думаю, будут уже практически работающий код.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обзор ECMAScript 6, следующей версии JavaScript