> So you are arguing in favor of approach #1, right?
>
> No, I am arguing against changing the meaning of [] on 'object'.
>
> Then I would make “your” Map a subtype of Object. typeof is currently best
> limited to primitives (and to distinguishing them from objects), so
> introducing a new result would suggest adding a new primitive.
>
> No, the goal is exactly to distinguish collections from objects.
>
> But I don’t think that is necessary: Once the semantics of [] have been
> changed in accordance with approach #1 then you can just write a library that
> provides Maps and other collections.
>
> We disagree. I don't want to fix old code, it works, let it be. I want new
> code to have a great new option. New tools can migrate developers to new
> options. And these things can happen in our lifetime.
How about approach #2, simply introducing a new kind of []?
Example: .[]
let map = new Map();
map["aNewMethod"] = function () { ... }; // a method
map.["first"] = "John Doe"; // a collection element
Advantages:
- No need to introduce a third kind of value (in addition to objects and
primitives).
- Map is simply a subtype of Object and can be implemented via a library and
possibly even ported to ECMAScript 5. Obviously method names such as get() and
put() would have to be used instead of .[]
- No surprise for users: [] currently converts its keys to strings, .[] could
be used for other kinds of keys, without breaking the ToString contract of []
It takes some getting used to, but it is conceptually very clear.
Axel
--
Dr. Axel Rauschmayer
[email protected]
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
