Comments 32
В примере используется `Set` для хранения строк. Если рассматривать `Set` именно с этой стороны, то это ничто иное как синтаксический сахар, не более (все описанное можно без проблем реализовать сейчас).
В чем реальный профит Set'а? В каких кейсах можно будет сказать «Здесь железно эффективнее Set, чем обычный массив.»?
Может быть есть пример как объект может выступать в роли ключа?
В чем реальный профит Set'а? В каких кейсах можно будет сказать «Здесь железно эффективнее Set, чем обычный массив.»?
Ключами могут быть только строки (strings) или, в случае ES6, символы. Объекты ключами быть не могут.
Может быть есть пример как объект может выступать в роли ключа?
+1
UFO just landed and posted this here
Мысль верная, но это спорный вопрос, где обе стороны правы. Вопрос именно в том, для решения какой нерешенной задачи нужен этот инструмент. Если ни для какой, и речь идет лишь об оптимизации производительности при работе с коллекциями, тогда вопрос снят.
-2
Это с чего бы по вашей прихоти снимается удобный и производительный инструмент? Как следствие для уймы задач он подходит.
Где для той же задачи (условно теперь получается костыльно) используется массив то вот вам и места применения в каждом втором коде.
Где для той же задачи (условно теперь получается костыльно) используется массив то вот вам и места применения в каждом втором коде.
+3
Это с чего бы по вашей прихоти снимается удобный и производительный инструмент?
Я нигде этого не написал, не преувеличивайте.
Где для той же задачи используется массив то вот вам и места применения в каждом втором коде.
Я так и написал, это лишь новый оптимизированный инструмент для работы с коллекциями.
условно теперь получается костыльно
Здесь тонкий момент.
У нас уже есть конструктор Array, который содержит методы для работы с массивами. Теперь появляется новая сущность, которая содержит часть методов от массива, и часть новых методов которых ему не хватало ранее. Получается, теперь у нас есть два неполноценных инструмента. Каждый из них имеет часть функциональности друг от друга, но полноценным не является ни один из них.
Получается, теперь если нам понадобится полноценно работать с коллекциями, тогда мы будем вынуждены брать одну из двух сущностей в зависимости от того, что больше нам подходит, и дополнять ее своими, как вы выразились, «костылями», чтобы заполнить недостающую нам функциональность.
Вы правы в том что это не самое красивое решение, и лучше это сделать нативно, но теперь это будет не решение без которого не обойтись, а фактически это будет велосипедом, и еще останется вопрос что будет работать быстрее, учитывая что горячие участки кода браузер умеет оптимизировать сам.
К чему это все — безусловно, хорошо что новый инструмент появился, но пока нет ни тестов производительности, ни новых решенных с его помощью задач, смысловой нагрузки он не несет. Если же инструмент себя оправдает, тогда это будет просто отлично.
-2
Вам просто указывают, что структура Set есть почти во всех языках, в стандартной библиотеке. Что такое множество (set) и где его использовать — основы программирования (изучают в школе или на первом курсе) и лежит вне плоскости этой статьи.
Оптимизация производительности как-бы одна из важнейших задач.
Вообщем, есть мнение что вы банально зашли потроллить. Толсто.
Вопрос именно в том, для решения какой нерешенной задачи нужен этот инструмент. Если ни для какой, и речь идет лишь об оптимизации производительности при работе с коллекциями
Оптимизация производительности как-бы одна из важнейших задач.
Вообщем, есть мнение что вы банально зашли потроллить. Толсто.
+4
Учитывая, что фактически аргументов кроме «это работает быстрее» и «это есть везде» (что по своей сути не является аргументом), я ничего не услышал. Поэтому, вопрос открыт. Не понимаю в чем здесь троллинг.
-1
пожалуйте в школу en.wikipedia.org/wiki/Set_(mathematics). Мне в повседневной практике очень часто требуется определять множество значений.
+1
Что вы на человека набросились. Он лишь сказал, что примеры в статье не показывают особых преимуществ set перед существующим подходом в JS.
И уж совсем моветоном ссылаться на основы программирования. То, что описывается, как множество, реализовывалось в JS и ранее, просто другими средствами.
Основной плюс — стало удобнее работать с коллекциями и они стали быстрее. И я думаю RomanYakimchuk просто хотел увидеть именно в чём стало удобнее и на сколько быстрее. Статья о другом, вот и всё.
И уж совсем моветоном ссылаться на основы программирования. То, что описывается, как множество, реализовывалось в JS и ранее, просто другими средствами.
Основной плюс — стало удобнее работать с коллекциями и они стали быстрее. И я думаю RomanYakimchuk просто хотел увидеть именно в чём стало удобнее и на сколько быстрее. Статья о другом, вот и всё.
+4
С обычными объектами (т.е. использовать {} со свойствами в качестве Set) так нельзя:
> var s = new Set(), obj = { my: 'object' }
> s.add(obj);
Set {Object {my: "object"}}
> s.add(obj);
Set {Object {my: "object"}} <--- один и тот же объект второй раз не добавился
0
Это коллекция из уникальных объектов. Это решенная задача.
0
Как она решается сейчас без библиотек и добавления свойств в объекты коллекции?
+1
Достаточно сделать метод который проверяет наличие элемента в массиве перед вставкой элемента.
-1
Я вас удивлю но решенных задач море. Но это никак не аргумент в данном случае.
0
Аргумент в пользу чего? Я не говорил что этот инструмент не нужен.
0
синтаксический сахар, не более
Получается, теперь у нас есть два неполноценных инструмента.
а фактически это будет велосипедом
Я потерялся в ходе ваших мыслей. Сдается речь о аргументе в пользу полезности/бесполезности.
0
Верно, мы ищем пользу от инструмента, но не решаем вопрос «нужен ли такой инструмент языку» :)
-1
Устраивается новичок на работу на лесопилку:
— это хорошо, что у вас есть пилорама, но это инструмент ненужный — есть же болгарка, ей можно всё сделать.
— но бревно на доски ей пилить долго и неудобно, не предназначена она для этого, да и в руках её надо держать..?
— тогда можно её в тиски зажать, а пилорама — бесполезная.
— это хорошо, что у вас есть пилорама, но это инструмент ненужный — есть же болгарка, ей можно всё сделать.
— но бревно на доски ей пилить долго и неудобно, не предназначена она для этого, да и в руках её надо держать..?
— тогда можно её в тиски зажать, а пилорама — бесполезная.
+4
Может быть есть пример как объект может выступать в роли ключа?
Если вы не заметили:
Во второй части про Map и слабые коллекции.
В структуре Set ключей нет.
Почему не надо писать свои велосипеды, вам уже сказали.
0
Set и Map, вероятно, удобнее и чище в использовании чем Array. Вероятно, он работает быстрее, и сделает Array устаревшим.
Здесь речь о другом — все это не привносит ничего нового. Все это давно реализовано и используется. Set и Map лишь упростит использование и даст возможность работать с коллекциями быстрее, не более.
Здесь речь о другом — все это не привносит ничего нового. Все это давно реализовано и используется. Set и Map лишь упростит использование и даст возможность работать с коллекциями быстрее, не более.
-4
«не более»?
Да каждого из этих двух улучшений достаточно чтобы добавить это в язык.
«упростит использование»
Set исправляет семантику языка. Если я реализую множество, я хочу везде видеть и знать, что это именно множество, а не что-то, что его может реализует, а может и нет. Что я банально буду в дебаггере видеть что это множество а не что-то другое.
Про скорость вообще мне кажется объяснять не надо. Скорость современного js критично важна, на нем сейчас слишком много всего пишется.
Да каждого из этих двух улучшений достаточно чтобы добавить это в язык.
«упростит использование»
Set исправляет семантику языка. Если я реализую множество, я хочу везде видеть и знать, что это именно множество, а не что-то, что его может реализует, а может и нет. Что я банально буду в дебаггере видеть что это множество а не что-то другое.
Про скорость вообще мне кажется объяснять не надо. Скорость современного js критично важна, на нем сейчас слишком много всего пишется.
+1
Да каждого из этих двух улучшений достаточно чтобы добавить это в язык.
Я этого не говорил.
Про скорость вообще мне кажется объяснять не надо. Скорость современного js критично важна, на нем сейчас слишком много всего пишется.
Протестировал на хроме: у меня добавление элементов в Set работает медленнее чем в массив.
-1
Добавление или добавление с проверкой есть ли уже такой элемент? Размеры массивов? Удаление элементов из середины?
Все ли учитывалось в тесте?
Ну и надо помнить что в Хроме хорошая эвристика по оптимизациям и искусственный тест может давать неверную картину.
Все ли учитывалось в тесте?
Ну и надо помнить что в Хроме хорошая эвристика по оптимизациям и искусственный тест может давать неверную картину.
0
jsperf лежит :( Нашел jsperf.com/es6-shim-vs-es6-collections но посмотреть не могу
0
Я ошибся в тесте.
Set работает на добавление одном уровне с массивом, но если сделать полный тест (проверка ключей, поиск индекса, все как обычно), тогда Set выигрывает в десятки раз. 100.000 итераций делал.
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');
+2
У них сервак лег из-за спамеров. Надеюсь, поднимут, им там разные хостеры предлагают помочь.
0
Собственно, что вы хотите увидеть в этом тесте? es6-shim и es6-collections? Коллекции из es6-collections реализованы поверх массивов и имеют время поиска элемента O(n). Коллекции es6-shim — цепочка вхождений и, для примитивов, индекс, время поиска элемента — O(n) для объектов и O(1) для примитивов, притом до недавнего времени es6-shim заменял быстрые нативные коллекции на свои медленные во всех движках, да и сейчас во многих. Так что и те, и те коллекции назвать настоящими язык не поворачивается, так как требование к сублинейному времени доступа содержится в стандарте ECMAScript. Используйте коллекции из core-js — O(1) для всех ключей, кроме иммутабельных объектов :)
0
Only those users with full accounts are able to leave comments. Log in, please.
Тонкости ES6: Коллекции (часть 1)