typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting
brendan at mozilla.com
Fri Aug 2 12:32:23 PDT 2013
Allen Wirfs-Brock wrote:
> The iterator factory methods of map are all just short-cuts for creating "MapIterator" objects which are current specified as "friends" (in the C++ sense) that know about internal key/value store encapsulated by Map objects. The current spec. for MapInterator was written before we added 'forEach' to Map and arguably it could be re-specified in terms of 'foreach'.
This is a minor point, but internal iteration (forEach) and external
(@@iterator) are not the same. How do you avoid rewriting to move the
external consumer code into the forEach callback? Rewriting source is out.
> However, that may take away some implementation level flexibility. Regardless, it's a possibility that I think I'll look into more deeply.
It's easier to layer internal iteration on external.
> Where we end up with is that the operations we would want for a Map-lite are get/set/delete/has/size/clear/forEach. They all need to know the implementation details of the underlying key/value store and for pragmatic reasons it doesn't make sense to try to reduce them to a smaller set of primitives.
> That is exactly the interface of ES6 Map except that Map adds the trivial iterator factory method. It simply isn't worth having the added complexity of distinct Map and Map-lite classes simply to not have the iterator factory methods. For ES6 Map is Map-lite
> 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.
More information about the es-discuss