Harmony collections NOW

[cst]

956,84 КБ картинка для привлечения внимания? о_О

[Jabher]

Да, только через час заметили, что в jpg тонкие линии пережимаются — на мониторе, на котором все это рисовалось, артефакты были незаметны. Заменили сначала на большой png, чуть позже увидели размер и пережали в png-8, теперь меньше сотни Кб весит картинка.

[pgg]

Какие-то проблемы?

[z6Dabrata]

Скорее бы

[MuLLtiQ]

Все бы неплохо, если бы еще и возможность перегружать equals, как в Java (или Dart) добавили.
А насчет дополнительного атрибута — это совсем не страшно, учитывая что в реализациях JS их и так используют (тот же __proto__, например).

[Jabher]

не страшно. Но становится невозможной привязка к Object.frozen()

[TheShock]

Проверять через Object.isFrozen и делать альтернативный текущий механизм для них?

[Jabher]

Я хотел бы попробовать при поддержке Брэндона сделать универсальный O(n) для ie8- и Object.frozen элементов + O(1) для всех остальных алгоритм в ближайшие несколько месяцев. Он согласился помочь, к сожалению, у меня не так много свободного времени на абсолютно универсальное решение WeakMap — для моего случая достаточно того решения, что сделал Брэндон, и это скорее будет работа из чистого любопытства.

[termi]

Спасибо за статью! Действительно крутой и нужный полифил.
Осталось только несколько вопросов:
1. В Benvie/WeakMap не реализован метод clear — нужно это указать в статье.
2. Конструктор Benvie/WeakMap не работает с Iterator protocol, только с массивами.
3. Не раскрыта тема WeakSet.

[mraleph]

к сожалению, написать leakless WeakMap shim невозможно:

var a = {}, b = {};
(function () {
  for (var i = 0; i < 10000; i++) {
    var map = new WeakMap;
    map.set(a, b);
  }
})();

var arr = [];

function A() { }
function B() { }

(function () {
  var map = new WeakMap;
  for (var i = 0; i < 1e3; i++) {
    var x = new A;
    arr.push(x);
    map.set(x, new B);
  }
})();

в обоих случаях память утечет (во-втором случае утечет B).

ничего особо weak или прорывного в хранении значений на ключе нет.

[Aquahawk]

А можете пояснить почему память утечёт в обеих случаях? Ведь и в первом и втором случаях по выходу из скойупа внешней функции мапы потеряют все внешние ссылки и должны быть собраны garbageCollector'ом? И экземпляры объектов(во втором случае) тоже должны быть собаны gc?

[mraleph]

Заметьте я говорю про shim описанный в статье. При нативной реализации WeakMap в JS VM, конечно же, ничего ни в первом, ни во втором случае не должно утечь (если утекает — то это баг в реализации :)).

А в shim описанном в статье утечет, потому что мы при выполнении m.set(x, y) мы по сути дела прикрепляем y сильным образом к x, там к x прикрепляется специальная структурка. По сути дела у нас произошла перестановка из Map * Key → Value мы делаем Key * Map → Value и храним значения на ключах, индексируя их мапами. Такой shim не течет в том смысле, что если ключ «помер», то мап не будет без дела удерживать значения, но до настоящей семантики он не дотягивает. Потому что если ключ не помер, то нем эта вспомогательная структурка будет вечно висеть и содержать (и удерживать) мертвые куски относящиеся к умершим мапам.

[Aquahawk]

А, всё осознал. Я свой вариант изобретал, так вот у меня есть идея как сделать так чтобы не текло в вышеприведённых кейсах. Вроде получается даже нормально. Как думаете это кому-нибудь нужно? Естественно с sealed и frozen объектами моя реализация тоже работать не будет.

[mraleph]

Если не будет утекать в этих кейсах, будет утекать в других. Невозможно реализовать правильную семантику WeakMap в виде shim — из сильных ссылок, слабые не соорудить.

[Aquahawk]

Я попробую соорудить концепт и показать.

[Aquahawk]

А, осознал, блин. У меня получилась жёсткая ссылка из мапы на значение. И если ключ будет собран а ссылка на мап будет висеть, то value утечёт.