"Subclassing" basic types in DOM - best method?

Erik Arvidsson erik.arvidsson at gmail.com
Tue Nov 20 09:38:57 PST 2012


On Tue, Nov 20, 2012 at 9:25 AM, 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)
>

That is not very nice.


> urlQuery.delete(name) -> delete urlQuery[name]
> urlQuery.delete(name, value) -> if (urlQuery[name]) { urlQuery[name] =
> urlQuery[name].filter(x => x !== value); }
>

I think the main issue with using an API like this is that you will end up
with conflicts between the storage space and the API space. In your
proposal there are no API methods but as soon as you add one you are
limiting the keys you can use. It seems very likely that you don't want
this to throw when people try to concat this with a string, so you add a
toString method. Now, what happens when you do urlQuery['toString'] or
worse urlQuery['__proto__'] = 'huh'?

This kind of problem is hurting people all the time when they use
localstorage


> "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
>



-- 
erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121120/ca8dc40a/attachment-0001.html>


More information about the es-discuss mailing list