On Fri, Aug 2, 2013 at 3:34 PM, Allen Wirfs-Brock <[email protected]> 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. ~TJ _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
