Non-generic traps for non-generic objects (was: Overriding Map/etc with get/set hooks?)

Allen Wirfs-Brock allen at
Fri May 31 09:52:48 PDT 2013


I don't think we have a consensus yet within TC39 WRT whether providing abstract classes of this sort  is a good idea for JS, so I would be reluctant to push the matter to the committee at this time.

I don't really see why it even needs to addressed at the implementation level at this time.  My reading of this thread is that Tab's major concern is that he wants to  use in web API specs a "Map-like" interface that is guaranteed to have all of the generic map methods that ES specifies for Map.prototype. He doesn't want to explicitly list them because that would be a spec. maintenance hassle. 

To me there seems to be a simple solution to that problem.  Just specify, using prose, in the WebIDL spec. that the "Map-like" interface has all of the methods defined by the host implementation of Map.prototype. Since we are in spec-land the job is done...

Note that we have a similar issue in the ES6 spec. WRT Array.prototype methods and TypedArray.  TC39 has already agreed that we want most of the Array methods to also be available as TypedArray methods. The current proposal accomplishes this by replicating the Array methods on a prototype that all TypedArray prototypes inherit from.  However, a reasonable alternative that some members have suggested is to make TypeArrays inherit from Array.prototype.  A less reasonable alternative is to actually refactor Array.prototype (mutating vs non-mutating methods, etc.).  We will have to resolve this one way or another this summer.


On May 31, 2013, at 8:05 AM, Jason Orendorff wrote:

> On Tue, May 28, 2013 at 7:15 PM, Tab Atkins Jr. <jackalmage at> wrote:
> > ES6 could provide a Mapping class, in a standard module, that works like
> > this:
> >
> >
> > All those methods are generic. Map would be a subclass of Mapping, with its
> > own fast non-generic methods [...]
> This would be *absolutely ideal*.  It would be cool if tc39 defined
> this; if not, WebIDL should be able to pick up the slack. [...]
> Is any TC39 member interested in putting this on the agenda for the next meeting?
> If DOM really wants this, ES (not WebIDL) should provide it.  WebIDL can't make Map a subclass of Mapping.
> -j
> _______________________________________________
> es-discuss mailing list
> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list