typeof extensibility, building on my Value Objects slides from Thursday's TC39 meeting

Brendan Eich 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 mailing list