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

Tab Atkins Jr. jackalmage at gmail.com
Thu Aug 1 17:36:47 PDT 2013

On Thu, Aug 1, 2013 at 5:29 PM, Brendan Eich <brendan at mozilla.com> wrote:
> Tab is still looking for a MapLite (tm) that can be customized with hooks.
> Obviously to avoid infinite regress, the MapLite bottoms out as native, and
> the hooks are on the outside (in Map). Tab, do I have this right?

Right.  Map has a medium-sized interface, with several methods that
don't provide new capabiltiies, but only convenience/performance.  As
well, I expect the interface to grow over time.

Making a Map subclass that needs to audit its data on input or output
is thus difficult, because when a new method gets added to Map, either
it's able to pierce through your interventions and get at the raw data
directly, or it simple doesn't work until you update.  Even for the
existing methods, you have to manually override the conveniences; just
overriding delete() just protect you against a clear().

MapLite has the smallest possible useful semantics for a Map
(basically, the same semantics that the spec uses in terms of
meta-operations), and thus is useful as an interception target.  You
can then just subclass Map and only override the MapLite at its core,
secure in the knowledge that new methods will Just Work (tm) in terms
of the provided bedrock operations on the MapLite.

> The even simpler course is to keep Map as spec'ed and make DOM or other
> specs work harder. Trade-offs...

The reason I'm really pushing on this is that it's not just DOM (we've
already made the trade-off there, by adding [MapClass] to WebIDL), but
user-space as well.  I can't make a safe Counter class that's built on
a Map unless I make the tradeoff above.

But this is a tangent.  ^_^


More information about the es-discuss mailing list