4 ms·

ES6 in Depth: Collections

61 points by shawndumas 11y ago

hayksaakian 11y ago
i love how the set examples use emoji > var desserts = new Set("🍪🍦🍧🍩"); > desserts.size 4 > desserts.add("🍪"); Set [ "🍪", "🍦", "🍧", "🍩" ] > desserts.size 4
spankalee 11y ago
It's too bad that JavaScript collections have ugly Java-like APIs, with get(k), set(k, v), etc. It would be nice if the [] and . weren't essentially aliases for each other, so that [] could be use for collections. There was once a proposal for this, though it would have broken assumptions of lots of code: http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation http://wiki.ecmascript.org/doku.php?id=strawman:object_model...
- TazeTSchnitzel 11y ago
  Sounds like a bad idea, [] and . have always acted directly on object properties. Changing the semantics of a basic language operator can have consequences you wouldn't envision. What if an existing function deals with a new object? Add a new operator, like {}.
  - pcwalton 11y ago
    I think using curly braces would be an automatic semicolon insertion hazard. You would at least need to introduce another "no LineTerminator here" rule.
    - TazeTSchnitzel 11y ago
      Sure, there might be a better syntactical choice, though I'm not sure what it would be.
      - xiaq 11y ago
        Use map(key). I learnt this "map as callable" idea fron clojure and wondered why it is not more common.
        epidemian 11y ago
        Yeap. I find it very elegant to be able consider maps as simply functions that map elements from one domain to another: a -> b. A set can then simply be consider a special case of map: a -> Bool. A definition like that can also make concepts like infinite sets much easier to conceive. It'd be nice to be able to express "the set of all prime numbers" or "a map between a person and their soul-mate: Peson -> Maybe(Person)" and have them be interchangeable with other Sets and Maps (of same type) on general operations like intersection, difference, etc. But i think this interpretation is at odds with the idea of maps and sets being data structures of a given size, where you add and remove things.
  - pekk 11y ago
    > [] and . have always acted directly on object properties. That was the bad idea, but as you suggest it really can't be fixed now.
    - TazeTSchnitzel 11y ago
      It's not at all a bad idea. It means you can look up properties on an object by expression, but gives you a short syntax for the common case.
STRML 11y ago
This is a very well-written piece and I really enjoyed reading Jorend's analysis of "Open" vs "Close" hash table performance [1] linked in the article. All four of these collection types are sorely needed in JS and will have many positive effects into the future. I am especially happy to have WeakSet, which virtually eliminates a number of pesky memory leak cases that happen all the time in DOM library code. ES has a bright future and it is great to see the committee making so many great choices while it grows. It is truly great that the community has not only been given significant opportunity to comment on and contribute to the spec, but to actually test code written with the new spec using transformers like Babel to ensure that they not only sound good, they work well in practice. What a breath of fresh air it is to evolve the web this way, rather than having a committee simply unilaterally define a specification (without a reference implementation) that turns out to be bug-prone, slow, or incomplete. 1. https://wiki.mozilla.org/User:Jorend/Deterministic_hash_tables https://wiki.mozilla.org/User:Jorend/Deterministic_hash_tabl...

61 points by shawndumas 11y ago

i love how the set examples use emoji > var desserts = new Set("🍪🍦🍧🍩"); > desserts.size 4 > desserts.add("🍪"); Set [ "🍪", "🍦", "🍧", "🍩" ] > desserts.size 4

spankalee 11y ago

It's too bad that JavaScript collections have ugly Java-like APIs, with get(k), set(k, v), etc. It would be nice if the [] and . weren't essentially aliases for each other, so that [] could be use for collections. There was once a proposal for this, though it would have broken assumptions of lots of code: http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation http://wiki.ecmascript.org/doku.php?id=strawman:object_model...

TazeTSchnitzel 11y ago
Sounds like a bad idea, [] and . have always acted directly on object properties. Changing the semantics of a basic language operator can have consequences you wouldn't envision. What if an existing function deals with a new object? Add a new operator, like {}.
- pcwalton 11y ago
  I think using curly braces would be an automatic semicolon insertion hazard. You would at least need to introduce another "no LineTerminator here" rule.
  - TazeTSchnitzel 11y ago
    Sure, there might be a better syntactical choice, though I'm not sure what it would be.
    - xiaq 11y ago
      Use map(key). I learnt this "map as callable" idea fron clojure and wondered why it is not more common.
      - epidemian 11y ago
        Yeap. I find it very elegant to be able consider maps as simply functions that map elements from one domain to another: a -> b. A set can then simply be consider a special case of map: a -> Bool. A definition like that can also make concepts like infinite sets much easier to conceive. It'd be nice to be able to express "the set of all prime numbers" or "a map between a person and their soul-mate: Peson -> Maybe(Person)" and have them be interchangeable with other Sets and Maps (of same type) on general operations like intersection, difference, etc. But i think this interpretation is at odds with the idea of maps and sets being data structures of a given size, where you add and remove things.
- pekk 11y ago
  > [] and . have always acted directly on object properties. That was the bad idea, but as you suggest it really can't be fixed now.
  - TazeTSchnitzel 11y ago
    It's not at all a bad idea. It means you can look up properties on an object by expression, but gives you a short syntax for the common case.

STRML 11y ago

This is a very well-written piece and I really enjoyed reading Jorend's analysis of "Open" vs "Close" hash table performance [1] linked in the article. All four of these collection types are sorely needed in JS and will have many positive effects into the future. I am especially happy to have WeakSet, which virtually eliminates a number of pesky memory leak cases that happen all the time in DOM library code. ES has a bright future and it is great to see the committee making so many great choices while it grows. It is truly great that the community has not only been given significant opportunity to comment on and contribute to the spec, but to actually test code written with the new spec using transformers like Babel to ensure that they not only sound good, they work well in practice. What a breath of fresh air it is to evolve the web this way, rather than having a committee simply unilaterally define a specification (without a reference implementation) that turns out to be bug-prone, slow, or incomplete. 1. https://wiki.mozilla.org/User:Jorend/Deterministic_hash_tables https://wiki.mozilla.org/User:Jorend/Deterministic_hash_tabl...