On Aug 2, 2013, at 12:32 PM, Brendan Eich wrote: > 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.
right, defining 'forEach' in terms of 'MapIterator' is the way to go. > >> 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. Me too, Allen _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
