typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting
Tab Atkins Jr.
jackalmage at gmail.com
Fri Aug 2 15:36:41 PDT 2013
On Fri, Aug 2, 2013 at 3:34 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> On Aug 2, 2013, at 12:32 PM, Brendan Eich wrote:
>> Allen Wirfs-Brock wrote:
>>> We can debate whether future new methods should be added to Map or be made part of distinct new classes.
>> I think this is the underlying concern (Tab can confirm).
>>> I'd suggest the latter for most cases. New methods are likely to incorporate domain concepts (eg, DOM stuff) that are not an essential part of the basic key/value store abstraction. It's better to define an appropriate domain specific abstraction that encapsulates a Map (or if you're an old school OO'er subclasses it) than it is to start adding new methods.
>> We should probably stack hands and even make this more than a suggestion. Between compatibility woes adding to Map.prototype later (see Array.prototype.values and @@unscopeable), and Tab's concern, I am ready to make it policy.
> Me too,
I'm fine with this, but if this happens, I suggest reviewing Python's
dict class and similar constructs in other languages to see if there's
any other core operations we'll want to add to the main Map object
before we freeze things.
For example, I think that Python's dict#update() isn't appropriate to
push to a subclass.
More information about the es-discuss