Comments 38
Хороший способ. Огорчает только то что такие объекты при кодировании в JSON и обратно перстают быть «голыми».
+3
Use polyfill, Luke.
-5
Стало интересно, насколько такие объекты быстрее, или медленнее обычных. Написал тест на jsperf-е.
На моем компьютере разница совсем незначительная.
На моем компьютере разница совсем незначительная.
+1
UFO just landed and posted this here
В том, что нельзя одновременно хранить toString и hasOwnProperty. Это ведь такой частый кейс!
+6
А как раз самый частый кейс, что свойство может оказаться методом, который for… in спокойно себе проитерирует, хотя нам нужны только данные
-1
Конечно, если в словарь положить функцию, то она там будет.
Тут, скорее, проблема в криворуком стороннем коде может быть. Вот тут да, лучше подстелить соломки.
Тут, скорее, проблема в криворуком стороннем коде может быть. Вот тут да, лучше подстелить соломки.
0
А какой другой код (положит)подложит туда toString и hasOwnProperty?
-1
А откуда свойство окажется методом?:)
Ну вообще prototype.js и прочие sugar.js (и не только) любят пошалить в прототипах встроенных объектов. Из-за них, в основном, все эти страшилки про «не используйте for..in».
Ну вообще prototype.js и прочие sugar.js (и не только) любят пошалить в прототипах встроенных объектов. Из-за них, в основном, все эти страшилки про «не используйте for..in».
0
> А откуда свойство окажется методом?:)
потому что функция — полноправный объект, а контроль типов у нас по определению отсутствует
> «не используйте for..in».
потому, что мы итерируем по ключам вместо значений, это идет вразрез со всеми языками.
потому что функция — полноправный объект, а контроль типов у нас по определению отсутствует
> «не используйте for..in».
потому, что мы итерируем по ключам вместо значений, это идет вразрез со всеми языками.
-1
Поэтому, кажется, придумали for-of. Осталось дождаться повсеместной поддержки. Честно говоря реализация в iojs не обрадовала =(
0
for-of не только эту проблему решает. А что там в iojs поломано на эту тему?
0
Из того что я запомнил: у меня не взлетело:
А жаль. Во многих местах пришлось отказаться от for-of из-за этого
for (var [key, value] of phoneBookMap)
А жаль. Во многих местах пришлось отказаться от for-of из-за этого
0
Мда, половина смысла теряется.
В babel работает, если что: github.com/hogart/alchemy/blob/fa4d02205fb4127d9e4d6a0524fb762752cead46/src/lib/alchemy.js#L16
В babel работает, если что: github.com/hogart/alchemy/blob/fa4d02205fb4127d9e4d6a0524fb762752cead46/src/lib/alchemy.js#L16
0
Полез смотреть где я вообще эти [] углядел. Увидел я их в статье на frontender.info. Но не обратил внимания на то, что там речь шла о Map. Впрочем это не отменяет того факта, что iojs ругался на синтаксис.
Тогда моя претензия больше к самой конструкции, хочется иметь сразу и ключ. Но похоже это претит самому принципу доступа через итераторы. Во всяком случае здесь я не нашёл решений.
Тогда моя претензия больше к самой конструкции, хочется иметь сразу и ключ. Но похоже это претит самому принципу доступа через итераторы. Во всяком случае здесь я не нашёл решений.
0
Нет, должно работать так, как вы и хотели: www.2ality.com/2015/02/es6-iteration.html, пример в пункте 2.3. Все зависит от того, что именно лежит в итерируемом под ключом Symbol.iterator. Ну и деконструкция должна тоже работать, я не помню, поддерживается она в iojs или нет.
В моем примере по ссылке используется Array#entries, который итерирует по парам индекс-значение.
В моем примере по ссылке используется Array#entries, который итерирует по парам индекс-значение.
0
Есть еще одна засада — объект невозможно отсортировать, в то время как массив — пожалуйста.
Поэтому, увы, как бы нам не хотелось, это не полноценная замена ассоциативным массивам.
Поэтому, увы, как бы нам не хотелось, это не полноценная замена ассоциативным массивам.
-1
В качестве частного решения можно предложить такое:
Но, если честно, не помню, чтобы мне был нужен хэш, ключи в котором располагаются в определенном порядке. Приведите кейс, если не трудно?
Object.keys(obj).sort().forEach // ну или .map, смотря что нужно сделать
Но, если честно, не помню, чтобы мне был нужен хэш, ключи в котором располагаются в определенном порядке. Приведите кейс, если не трудно?
0
Я натыкался на эти грабли в 2011 году (когда только осваивал javascript). Использовал hash вместо массива, в качестве ключа были id-ки. В качестве значений нечто вроде: {id: int, position: int, ...}. Данные приходили из PHP, в котором сохранялся изначальный порядок сортировки (по position). А браузеры вели себя по разному. В итоге переделал на массивы. Хотя казалось, что будет удобнее иметь прямой доступ по id.
Не уверен, что сие описание сгодится как нормальный case, но меня на тот момент, такое поведение удивило :)
Не уверен, что сие описание сгодится как нормальный case, но меня на тот момент, такое поведение удивило :)
-1
Насколько мне известно, такое поведение (определенный порядок ключей в словаре) только в PHP есть. Новички в Python, например, любят написать свой OrderedDict.
Вообще да, иногда хочется и быстрый доступ по id и итерацию по порядку — ну так, для красоты. Но обычно можно либо обойтись, либо воспользоваться какими-то обертками (Backbone.Collection, например).
Вообще да, иногда хочется и быстрый доступ по id и итерацию по порядку — ну так, для красоты. Но обычно можно либо обойтись, либо воспользоваться какими-то обертками (Backbone.Collection, например).
0
упс, не туда
0
> Object.keys(obj).sort().forEach
Тут вы получаете сортированные ключи, но не массив объектов.
В большинстве случаев сортировка должна производиться по содержимому. У меня такого вагон и маленькая тележка,
например
Вы в любом случае не отсортируете этот объект по полю value, в момент доступа он будет не отсортирован, вам будет нужен дополнительный массив для хранения порядка элементов. А конкретный бизнес пример — ну представьте что у вас есть таблица и строки в ней с ID. Это означает либо дополнительный массив для порядка, либо отсутствие доступа к строке по ID (если запихать эти объекты в обычный массив)
Тут вы получаете сортированные ключи, но не массив объектов.
В большинстве случаев сортировка должна производиться по содержимому. У меня такого вагон и маленькая тележка,
например
{
'foo': {
value: 3,
name: 'Vasya'
},
'bar': {
value: 2,
name: 'Petya'
}
}
Вы в любом случае не отсортируете этот объект по полю value, в момент доступа он будет не отсортирован, вам будет нужен дополнительный массив для хранения порядка элементов. А конкретный бизнес пример — ну представьте что у вас есть таблица и строки в ней с ID. Это означает либо дополнительный массив для порядка, либо отсутствие доступа к строке по ID (если запихать эти объекты в обычный массив)
0
Object.keys(obj).sort(function (key1, key2) { return obj[key1].value - obj[key2].value })
+2
Отдельные индексы универсальнее и гибче — можно задавать разный порядок, можно кэшировать и мгновенно переключать сортировку, можно комбинировать сортировку с фильтрацией и т.п.
0
UFO just landed and posted this here
Для более функциональных структур данных придется подождать ES6 (ES2015), который предоставит нам нативные ассоциативные массивы в виде объектов Map, Set и других. А пока этот радужный момент не настал
Да ведь они уже везде реализованы, и недавно я с большим удовольствием и пользой использовал нативную Map (правда, в проекте только для Fx29+).
0
UFO just landed and posted this here
Что примечательно, запустил один и тот же код по созданию млрд обычных объектов и млрд голых. Память оба процесса расходуют одинаково. А вот процессорное время голые съели заметно больше, чем обычные.
Обычные объекты создались за 43 с хвостиком секунды процессорного времени.
Голые съели больше 4х минут.
Скриншот прилагается. Node v0.10.26
![](https://habrastorage.org/r/w1560/files/f63/944/b79/f63944b795c0457b8eadf089452e966d.png)
Обычные объекты создались за 43 с хвостиком секунды процессорного времени.
Голые съели больше 4х минут.
Скриншот прилагается. Node v0.10.26
![](https://habrastorage.org/files/f63/944/b79/f63944b795c0457b8eadf089452e966d.png)
+2
Круто, а можете так же сравнить:
Может это Object.create не оптимизирован.
var normal = Object.create(Object.prototype);
var naked = Object.create(null);
Может это Object.create не оптимизирован.
+2
Да, Вы правы по поводу
Поротестировал много разных вариантов прототипов.
Результаты приблизительно одинаковы везде — 4 минуты ± 15 секунд.
Тест показывал неоптимизированность именно
Сами тесты проводил самыми стандартными средствами: readline-интерфейс node и top с фильтром результатов по pid.
Есть еще один хороший сервис тестирования, но через браузер: jsperf.com/naked-vs-simple-objects
Тут надо быть вимательным, результаты отличаются в разных браузерах на разных ОС.
Также, по заявкам трудящихся на комментарий ниже, к утру потестирую вышеперечисленное на node v0.12.4.
Object.create()
.Поротестировал много разных вариантов прототипов.
Результаты приблизительно одинаковы везде — 4 минуты ± 15 секунд.
Тест показывал неоптимизированность именно
Object.create()
.Сами тесты проводил самыми стандартными средствами: readline-интерфейс node и top с фильтром результатов по pid.
Есть еще один хороший сервис тестирования, но через браузер: jsperf.com/naked-vs-simple-objects
Тут надо быть вимательным, результаты отличаются в разных браузерах на разных ОС.
Также, по заявкам трудящихся на комментарий ниже, к утру потестирую вышеперечисленное на node v0.12.4.
+1
Интересно бы ещё посмотреть ситуацию на 12-ой.
0
Итак, скрин делать не буду. Оставлю результаты текстом.
Node v0.12.4
Node v0.12.4
for(var i = 0, l = 1000 * 1000 * 1000; i < l; i++) { var obj = {} } // => 0:07.29
for(var i = 0, l = 1000 * 1000 * 1000; i < l; i++) { var obj = new Object() } // => 0:34.58
for(var i = 0, l = 1000 * 1000 * 1000; i < l; i++) { var obj = Object.create(Object.prototype); } // => 1:11.67
for(var i = 0, l = 1000 * 1000 * 1000; i < l; i++) { var obj = Object.create(null) } // => 1:50.54
+3
Отличная статья!
Идея (по крайней мере, для меня) новая, и, разумеется, имеет полное право на существование.
Но, ситуация, которую описывает Автор, скорее — ошибка проектирования, нежеле фича JavaScript. Это стоило бы отметить в статье. Сама статья может служить отличным гайдом, как исправить схожую ошибку проектирования на этапе программирования (когда все форматы для обмена и хранения данных утверждены, и нет возможности внести коррективы).
От себя хотел выделить правило: Никогда не используй название свойств объектов JS для хранения даннных. Свойства объектов используем только для структурирования данных.
Хранение данных в названиях свойств объектов равносильно хранению данных в названиях столбцов в таблицах реляционных СУБД.
Выше, в комментариях, обсуждалась технологическая проблема, в следствии которой приходилось держать отдельный массив для быстрого доступа к данным по сложному ключу или для сортировки этих данных. В теории СУБД такие массивы называются индексами. В использовании массивов такого назначения нет ничего плохого.
Если не нравится то, что приходится использовать несколько разных массивов с разными именами, один из самых производительных способов — создать свой класс, наследуемый от Array или Collection. Ну, и реализовать работу всех индексов в рамках этого класса.
Идея (по крайней мере, для меня) новая, и, разумеется, имеет полное право на существование.
Но, ситуация, которую описывает Автор, скорее — ошибка проектирования, нежеле фича JavaScript. Это стоило бы отметить в статье. Сама статья может служить отличным гайдом, как исправить схожую ошибку проектирования на этапе программирования (когда все форматы для обмена и хранения данных утверждены, и нет возможности внести коррективы).
От себя хотел выделить правило: Никогда не используй название свойств объектов JS для хранения даннных. Свойства объектов используем только для структурирования данных.
Хранение данных в названиях свойств объектов равносильно хранению данных в названиях столбцов в таблицах реляционных СУБД.
Выше, в комментариях, обсуждалась технологическая проблема, в следствии которой приходилось держать отдельный массив для быстрого доступа к данным по сложному ключу или для сортировки этих данных. В теории СУБД такие массивы называются индексами. В использовании массивов такого назначения нет ничего плохого.
Если не нравится то, что приходится использовать несколько разных массивов с разными именами, один из самых производительных способов — создать свой класс, наследуемый от Array или Collection. Ну, и реализовать работу всех индексов в рамках этого класса.
+1
function AssocArray() {}
AssocArray.prototype = null;
Смысл, ведь, тот же?
А тест производительности что-то врет, видимо.
На моей машине в Chrome 43.0.2357.81 m 1M объектов {} создается за ≈1.5 сек, в то время как new AssocArray занимает ≈1.7 сек, а Object.create(null) — ≈2.1 сек.
+2
Sign up to leave a comment.
Настоящие ассоциативные массивы в JavaScript