"Subclassing" basic types in DOM - best method?

Alex Russell alex at dojotoolkit.org
Tue Nov 20 02:04:13 PST 2012

On Nov 19, 2012, at 11:16 PM, "Tab Atkins Jr." <jackalmage at gmail.com> wrote:

> 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...)

You can preserve all of those invariants + instanceof checking with proxies, or a subclass that simply over-writes the set methods to blow up on on-strike key/value setting. Either way, it doesn't seem particularly difficult and doesn't, to my mind, reduce the utility of having actual JS-native types as the baseline from which we design/subclass over in DOM.

Alex Russell
slightlyoff at google.com
slightlyoff at chromium.org
alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723

More information about the es-discuss mailing list