"Subclassing" basic types in DOM - best method?

Alex Russell slightlyoff at google.com
Tue Nov 20 08:13:19 PST 2012


I think the basic issue here is that DOM is over-specifying the constraints
(I assume because WebIDL makes that most natural?), not the available JS
hacks to implement their weirdo type constraints. Lets not feed the
misdesign trolls = )


On Tue, Nov 20, 2012 at 2:25 PM, Domenic Denicola <
domenic at domenicdenicola.com> wrote:

> For URLQuery in particular, since it's a String->String map, why not just
> use a plain-old-JavaScript-object with appropriate interceptions via a
> proxy? This provides a much more idiomatic API:
>
> new URLQuery(object) stays the same
> urlQuery.get(name) -> urlQuery[name][0]
> urlQuery.getAll(name) -> urlQuery[name]
> urlQuery.set(name, values) -> urlQuery[name] = values; use proxy here
> urlQuery.add(name, values) -> urlQuery[name].push(...values); use proxy
> here
> urlQuery.has(name) -> Object.prototype.hasOwnProperty.call(urlQuery, name)
> urlQuery.delete(name) -> delete urlQuery[name]
> urlQuery.delete(name, value) -> if (urlQuery[name]) { urlQuery[name] =
> urlQuery[name].filter(x => x !== value); }
>
> "use proxy here" means use it to do argument validation and manipulation
> of the associated URL object, with percent-encoding.
>
> The above assumes you want urlQuery[name] to always be an array;
> alternatively it could be either a string or array of strings, with
> appropriate magic behavior for either.
>
>
> > -----Original Message-----
> > From: es-discuss-bounces at mozilla.org [mailto:es-discuss-
> > bounces at mozilla.org] On Behalf Of Tab Atkins Jr.
> > Sent: Monday, November 19, 2012 18:16
> > To: es-discuss
> > Subject: "Subclassing" basic types in DOM - best method?
> >
> > 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
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121120/183f73c7/attachment.html>


More information about the es-discuss mailing list