На очередном собрании Генеральной Ассамблеи ECMA (http://www.ecma-international.org/) официально утверждён (https://mail.mozilla.org/pipermail/es-discuss/2016-June/0462...) стандарт ECMAScript 2016 (http://www.ecma-international.org/ecma-262/7.0/index.html) (ECMAScript 7 или "ECMA-262 7th edition"), определяющий базовые функциональные возможности JavaScript. ECMAScript 7 примечателен переходом (https://www.opennet.me/opennews/art.shtml?num=44355) к новому непрерывному процессу формирования стандартов, которые планируется выпускать ежегодно. Напомним, что прошлый стандарт ECMAScript 6 был утверждён в июне прошлого года, спустя шесть лет с момента принятия ECMAScript 5, и содержал достаточно большую порцию новшеств, которые ещё не полностью (http://kangax.github.io/compat-table/es7/) реализованы в современных браузерах.
В отличие от ECMAScript 6 спецификация ECMAScript 7 содержит относительно немного изменений, которые развивались в рамках непрерывно обновляемого варианта спецификации ECMAScript Next (http://kangax.github.io/compat-table/esnext/). В стандарт из данной черновой спецификации были перенесены уже поддерживаемые браузерами возможности, поэтому ECMAScript 7 сразу доступен во всех основных браузерах и не требует дополнительного времени на реализацию.
В ECMAScript 7 вошли изменения, связанные с устранением недоработок и внесением уточнений к ECMAScript 6, а также добавлено несколько новшеств (https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_...):
- Оператор "** (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...)" для возведения в степень. Например, вместо "Math.pow(x, y)" теперь можно указать
"x ** y";- Методы Array.prototype.includes() (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...) и TypedArray.prototype.includes() (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...) для определения наличия элементов в массиве. Напрмер, "[1, 2, 3].includes(2)" вернёт true, а "[1, 2, 3].includes(4)" вернёт false;
- Методы String.prototype.padStart() (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...) и String.prototype.padEnd() (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...) для доведения строки до заданного размера путём добавления повторяющегося шаблона заполнения в начало или конец строки. Например, 'abc'.padEnd(10, "foo") выдаст "abcfoofoof", а 'abc'.padEnd(6,"123465") выдаст "abc123";
- Для генераторов и методов генераторов больше не вызываются конструкторы;URL: https://mail.mozilla.org/pipermail/es-discuss/2016-June/0462...
Новость: http://www.opennet.me/opennews/art.shtml?num=44618
> String.prototype.padStart() и String.prototype.padEnd()это на них так модуль удаленный из npm повлиял?
Спецификация была ещё с июля 2015 года, а в stage 3(говорит вендорам, что пора бы уже у себя это запилить) было уже в ноябре того же года
>ECMAScript 7 примечателен переходом к новому непрерывному процессу формирования стандартовWe need to go deeper. Ждем стандарт на процесс формирования стандартов.
Было бы неплохо, кстати
ГОСТ Р 1.2-92
Если стандарт не международный - это не стандарт. тем более в IT.
Странные ребята, .includes() с одной стороны нужен, а с другой уже есть .indexOf, лучше бы форматирование дат сделали, чем дублировать фукционал.
indexOf в отличии от includes например не отреагирует на NaN
[NaN].indexOf(NaN); // -1
[NaN].includes(NaN); // true
> [NaN].includes(NaN); // trueОтлично! Экспектед бихевиор. Особенно учитывая что NaN != NaN. Консистентно, че.
И к чему этот пассаж? NaN найти в массиве (без ручного перебора) можно найти только таким методом.
> И к чему этот пассаж? NaN найти в массиве (без ручного перебора)
> можно найти только таким методом.Если ищете именно NaN, то есть isNaN() и перебор по массиву. По моему разумению NaN это сугубо ошибочный результат неких вычислений, и его не то что искать в массиве не надо, его нужно туда не класть, потому что он никчемен и не может быть полезным образом использован далее. На человеческом языке это "хрень непонятная". Никуда её толком не воткнешь. Об этом намекает спецификация языка в которой закреплено что NaN != NaN. Одна хрень не равна другой хрени.
Не вижу никакой силы в аргументе с поиском NaN в методе includes(). Это просто слабый аргумент.
Интересно, где-то реализован полный набор:
+-NaN Null +-Inf unassigned
одновременно?
indexOf возвращет индекс найденного элемента иначе -1, а includes возващает булево значение.
> indexOf возвращет индекс найденного элемента иначе -1, а includes возващает булево значение.Все, капут!! -1 к булевому не привести!
[1,2,3].indexOf(2) !== -1
или
!!~[1,2,3].indexOf(2)стало
[1,2,3].includes(2)
indexOf не найдет NaN, успокойся. Также includes можно передать стартовую позицию для поиска (это явно быстрее перебора с нулевой позиции indexOf в огромных массивах).
Учитывая что в js NaN != NaN, довольно странное поведение, да и вообще сложно представить когда это нужно, а у indexOf так же есть стартовая позиция https://developer.mozilla.org/en/docs/Web/JavaScript/Referen...
> indexOf не найдет NaN, успокойся.Спокойствие дороговато выходит.
Раньше разработчику нужно было только помнить, что indexOf не найдет NaN, потому что NaN !== NaN.
Теперь ему еще нужно помнить, что include найдет NaN, несмотря на то, что NaN !== NaN.Мне одному это напоминает Пых?
Array.prototype.includes в данном вопросе ведет себя так же, как и Set.prototype.has. Все вполне логично. Если зачем-то понадобился индекс NaN, делаешь array.findIndex(isNaN).
Вы, возможно, удивитесь, но все это продолжает напоминать все тот же Пых: какие-то элементы языка имеют свою логику, но она не состыкована со всем остальным языком...
>> indexOf возвращет индекс найденного элемента иначе -1, а includes возващает булево значение.
> Все, капут!! -1 к булевому не привести!
> [1,2,3].indexOf(2) !== -1
> или
> !!~[1,2,3].indexOf(2)
> стало
> [1,2,3].includes(2)По вашей логике ненужно было вводить классы - прототипы все наше, ненужны "обещания", генераторы - юзаем колбеки везде и всюду. Изначально разные предназначения у этих функций.
indexOf вынужден выдавать порядковый номер. includes от этого ограничения свободен, а значит может быть реализован совсем другим способами, дающим для больших массивов различие в скорости нахождения на порядки.
И в яваскрипте до сих пор нет ОДНОГО метода для очищения всего массива без мороки с количеством элементов?
delete
> И в яваскрипте до сих пор нет ОДНОГО метода для очищения всего
> массива без мороки с количеством элементов?Какой мароки? arr.length = 0;
var a = [1,2,3,4,5];
a.length = 0;
console.log(a); // --> [];
> клоун: Сразу видно уровень специалистов. Слово "метод" вам просто так написали?
> a = [1,2,3][1, 2, 3]
> Array.prototype.emptyMe = function(){ this.length = 0;}
> a.emptyMe()
> a[]
пользуйся и не плач
Если клоун - грустный, то пускай плачет. Цирк должен продолжаться.
Главное чтобы современные браузеры поспевали за стандартами...
на удивление с этим всё неплохо, глядишь через годик можно будет уже и о babel забыть
От бабеля вряд ли можно будет отказаться, но пресет es2015 можно уже отключать
Оказывается есть не только Генеральная Ассамблея ООН, но еще и про JavaScript. Круто, че
Бронзовеют на глазах ...
Интересно а Уполномоченный Генеральный Секретарь и Почётный Президент JavaScript тоже есть\будет? :)
Оператор возведения в степень сейчас нужен как никогда.
> Методы String.prototype.padStart() и String.prototype.padEnd() для доведения строки до заданного размераЭто же что же, left-pad.io теперь не нужен?
Следующий стандарт ES: однострочник на питоне добавлено Array.prototype.123 и Array.prototype.helloworld
Надо было значащие пробелы ввести. Было бы весело.
Чего там с байткодом JavaScript когда уже бинарный JS в браузеры можно будет компилить и предоставлять?
Никогда. Почти что есть WebAssembly - но это не джаваскрипт.
скорее всего никогда. для этого придется ввести типы, а на это врядли пойдут.
Из чего возникает необходимость обязательного введения типов для компиляции в байткод?
Скажу страшное, типы не являются необходимостью даже для компиляции в нативный код. Но дурачки выучили, что компилируемые языки это круто, в известных им компилируемых языках есть типы, значит без типов вообще никак. Такая вот "логика". А что такое байткод они скорее всего вообще не знают.
Можно даже поиздеваться над ламерами и сообщить им, что javascript вообще-то относится к типизированным языкам.
> "ECMA-262 7th edition"Прямо намёк Дэвиду Флэнагану, на то, что пора обновлять книгу. :-)
Да, обновлять. Причем ежегодно.
> Да, обновлять. Причем ежегодно.Ну не каждый год, но хотя бы раз в 5 лет.
6-ое издание на русском вышло аж в 2012 году, на английском, скорее всего в 2011.
Пора уже.
Вот честно, ну не тем народ занимается.Делают какую то хрень, была же нормальная идея с worker, забросили.
Или вот бинарные данные, прием, передача, сериализация в/из объект, начали что то, появились массивы, ура здорово ну шагните дальше, опять запросили.
Sqllite в веб, ура !! наконец то можно нормально сортировать и искать данные, ну нет все засрали колбеками, а все нормальное не реализовано.
И так все.
Как дети, у них тоже так, идея, коек как реализовали, и все уже не интересно.
в последнем хроме итерирование по массиву в 8 раз медленней чем выборка по индексу - это какой то позор