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

Allen Wirfs-Brock allen at wirfs-brock.com
Fri Aug 2 15:34:14 PDT 2013


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



More information about the es-discuss mailing list