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.
/be _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
