"Subclassing" basic types in DOM - best method?

Tab Atkins Jr. jackalmage at gmail.com
Mon Nov 19 15:16:05 PST 2012


For several things in the DOM and related APIs, we want objects that
are more-or-less the same as some basic ES stuff, like Arrays or Maps,
and which are appropriate to treat as those objects in a generic
manner.

For example, the URLQuery interface in the URL Standard
<http://url.spec.whatwg.org/#interface-urlquery>, which represents the
query portion (key/value pairs) of a URL, is basically a Map.  (It's
missing a few pieces right now, like has() and the iterator-producing
functions, but Anne plans to add them.)

Ideally, an author could take a library with generic Map-manipulating
functions, pass a URLQuery object in, and have a reasonable chance of
having that just succeed.  Hopefully, this should be robust to common
type-checking operations, like doing a structural test, or an
instanceof test.

Naively, this is doable just by subclassing Map (in the standard proto
way), and overriding the methods, to delegate to the Map methods and
then do additional things.  AWB posted some code to WHATWG detailing
how you would do this in ES5 and ES6; it's predictably simple.

However, URLQuery has some invariants it needs to maintain: it's a
String->String map, not Any->Any.  As such, it probably doesn't want
to actually initialize itself as a Map and forward to the Map methods;
instead, it should probably maintain a hidden internal Map and control
the access to that itself, so it can ensure that no non-Strings leak
into the map.

If we did this, the only reason to continue subclassing Map is to get
instanceof checks to work.  Is this acceptable?  Are there better
ways, perhaps on the horizon?  Any other thoughts?

(Further examples: NodeList being an Array, URLFragments being an
Array, a few DOM->CSS bridges being Maps...)

~TJ


More information about the es-discuss mailing list