Тонкости ES6: Коллекции (часть 1)

[yakimchuk-ry]

В примере используется `Set` для хранения строк. Если рассматривать `Set` именно с этой стороны, то это ничто иное как синтаксический сахар, не более (все описанное можно без проблем реализовать сейчас).

В чем реальный профит Set'а? В каких кейсах можно будет сказать «Здесь железно эффективнее Set, чем обычный массив.»?

Ключами могут быть только строки (strings) или, в случае ES6, символы. Объекты ключами быть не могут.

Может быть есть пример как объект может выступать в роли ключа?

[yakimchuk-ry]

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

[IncorrecTSW]

Это с чего бы по вашей прихоти снимается удобный и производительный инструмент? Как следствие для уймы задач он подходит.
Где для той же задачи (условно теперь получается костыльно) используется массив то вот вам и места применения в каждом втором коде.

[yakimchuk-ry]

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

Я нигде этого не написал, не преувеличивайте.

Где для той же задачи используется массив то вот вам и места применения в каждом втором коде.

Я так и написал, это лишь новый оптимизированный инструмент для работы с коллекциями.

условно теперь получается костыльно

Здесь тонкий момент.

У нас уже есть конструктор Array, который содержит методы для работы с массивами. Теперь появляется новая сущность, которая содержит часть методов от массива, и часть новых методов которых ему не хватало ранее. Получается, теперь у нас есть два неполноценных инструмента. Каждый из них имеет часть функциональности друг от друга, но полноценным не является ни один из них.

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

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

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

[IncorrecTSW]

Как нету тестов? jsperf или например benchmark вам в помощь. Чего нет напишите сами.

К слову почему только браузер? Есть есть еще серверная сторона.
Если появился новый инструмент под требуемую задачу и он работает быстрей чем старый костыль то он именно без которого нельзя обойтись а не велосипед.

[Ununtrium]

Вам просто указывают, что структура Set есть почти во всех языках, в стандартной библиотеке. Что такое множество (set) и где его использовать — основы программирования (изучают в школе или на первом курсе) и лежит вне плоскости этой статьи.

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

Оптимизация производительности как-бы одна из важнейших задач.

Вообщем, есть мнение что вы банально зашли потроллить. Толсто.

[yakimchuk-ry]

Учитывая, что фактически аргументов кроме «это работает быстрее» и «это есть везде» (что по своей сути не является аргументом), я ничего не услышал. Поэтому, вопрос открыт. Не понимаю в чем здесь троллинг.

[AlexeyFrolov]

пожалуйте в школу en.wikipedia.org/wiki/Set_(mathematics). Мне в повседневной практике очень часто требуется определять множество значений.

[kibitzer]

Что вы на человека набросились. Он лишь сказал, что примеры в статье не показывают особых преимуществ set перед существующим подходом в JS.

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

Основной плюс — стало удобнее работать с коллекциями и они стали быстрее. И я думаю RomanYakimchuk просто хотел увидеть именно в чём стало удобнее и на сколько быстрее. Статья о другом, вот и всё.

[yakimchuk-ry]

Это коллекция из уникальных объектов. Это решенная задача.

[yakimchuk-ry]

Достаточно сделать метод который проверяет наличие элемента в массиве перед вставкой элемента.

[yakimchuk-ry]

Правильно, поэтому я и написал, что производительность это плюс.

[IncorrecTSW]

Я вас удивлю но решенных задач море. Но это никак не аргумент в данном случае.

[yakimchuk-ry]

Аргумент в пользу чего? Я не говорил что этот инструмент не нужен.

[IncorrecTSW]

синтаксический сахар, не более

Получается, теперь у нас есть два неполноценных инструмента.

а фактически это будет велосипедом

Я потерялся в ходе ваших мыслей. Сдается речь о аргументе в пользу полезности/бесполезности.

[yakimchuk-ry]

Верно, мы ищем пользу от инструмента, но не решаем вопрос «нужен ли такой инструмент языку» :)

[fogone]

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

[Ununtrium]

Может быть есть пример как объект может выступать в роли ключа?

Если вы не заметили:

Во второй части про Map и слабые коллекции.

В структуре Set ключей нет.

Почему не надо писать свои велосипеды, вам уже сказали.

[yakimchuk-ry]

Set и Map, вероятно, удобнее и чище в использовании чем Array. Вероятно, он работает быстрее, и сделает Array устаревшим.
Здесь речь о другом — все это не привносит ничего нового. Все это давно реализовано и используется. Set и Map лишь упростит использование и даст возможность работать с коллекциями быстрее, не более.

[Ryotsuke]

«не более»?

Да каждого из этих двух улучшений достаточно чтобы добавить это в язык.

«упростит использование»
Set исправляет семантику языка. Если я реализую множество, я хочу везде видеть и знать, что это именно множество, а не что-то, что его может реализует, а может и нет. Что я банально буду в дебаггере видеть что это множество а не что-то другое.

Про скорость вообще мне кажется объяснять не надо. Скорость современного js критично важна, на нем сейчас слишком много всего пишется.

[yakimchuk-ry]

Да каждого из этих двух улучшений достаточно чтобы добавить это в язык.

Я этого не говорил.

Про скорость вообще мне кажется объяснять не надо. Скорость современного js критично важна, на нем сейчас слишком много всего пишется.

Протестировал на хроме: у меня добавление элементов в Set работает медленнее чем в массив.

[Ryotsuke]

Добавление или добавление с проверкой есть ли уже такой элемент? Размеры массивов? Удаление элементов из середины?
Все ли учитывалось в тесте?
Ну и надо помнить что в Хроме хорошая эвристика по оптимизациям и искусственный тест может давать неверную картину.

[Ryotsuke]

jsperf лежит :( Нашел jsperf.com/es6-shim-vs-es6-collections но посмотреть не могу

[yakimchuk-ry]

Я ошибся в тесте.

Set работает на добавление одном уровне с массивом, но если сделать полный тест (проверка ключей, поиск индекса, все как обычно), тогда Set выигрывает в десятки раз. 100.000 итераций делал.

var foo = [], index, bar;

console.time('test');

for (index = 100000; index--;) { bar = Math.random(); if (foo.indexOf(bar) === -1) {foo.push(bar);} }

console.timeEnd('test');

var foo = new Set(), index, bar;

console.time('test');

for (index = 100000; index--;) { bar = Math.random(); if (!foo.has(bar)) {foo.add(bar);} }

console.timeEnd('test');

[hoack]

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

[Ununtrium]

У них сервак лег из-за спамеров. Надеюсь, поднимут, им там разные хостеры предлагают помочь.

[rock]

Собственно, что вы хотите увидеть в этом тесте? es6-shim и es6-collections? Коллекции из es6-collections реализованы поверх массивов и имеют время поиска элемента O(n). Коллекции es6-shim — цепочка вхождений и, для примитивов, индекс, время поиска элемента — O(n) для объектов и O(1) для примитивов, притом до недавнего времени es6-shim заменял быстрые нативные коллекции на свои медленные во всех движках, да и сейчас во многих. Так что и те, и те коллекции назвать настоящими язык не поворачивается, так как требование к сублинейному времени доступа содержится в стандарте ECMAScript. Используйте коллекции из core-js — O(1) для всех ключей, кроме иммутабельных объектов :)