> 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 a...@rauschma.de twitter.com/rauschma home: rauschma.de blog: 2ality.com
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss