URLs / subclassing JavaScript

Sam Tobin-Hochstadt samth at ccs.neu.edu
Mon Dec 17 11:27:46 PST 2012


On Mon, Dec 17, 2012 at 9:19 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
> If down the road we want to allow for the theoretical possibility of
> having all platform APIs implemented in JavaScript, we might want a
> sync Object.observe. If we have types down the road as well (this
> might be a bit presumptuous), URLQuery could just be a MultiMap and
> whenever the MultiMap was mutated you'd update the associated URL
> synchronously (and potentially do other things, such as navigating to
> a URL). The latter would require synchronous change delivery. Or I
> suppose some kind of subclass that changes all the manipulation
> methods to also perform some kind of notification.
>
> I guess the problems here are that a) there's no MultiMap b) there's
> no types c) we want to reduce the burdon on developers for doing URL
> manipulation probably without waiting for a/b, but I rather not pull a
> Typed Array.

First, I don't really see what types are doing in this discussion.
Are you thinking about classes?

Second, by far the easiest way to accomplish all of this would be to
just make `URLQuery` implement the same interface as a MultiMap (and a
Map).  Then there's no need for any observation, or proxies, or any of
that, since Maps are carefully designed to be implementable entirely
in JS.  As far as I can see, some deeper tying of URLQuery to a
platform-builtin MultiMap would accomplish potentially the following:

  - making `instanceof` work in a few cases.
  - allowing use of MultiMap.prototype.get.call on a URLQuery.
  - anything else?

I think `instanceof` is irrelevant, and that functions that expect
MultiMaps or URLQuerys should just use the `m.get()` of the value they
have, and not expect nominal typing. [1]

> Oh, and by the way, I read
> http://infrequently.org/2012/12/reforming-the-w3c-tag/#comment-240289
> the other day. 1) In so far there would be an organisation responsible
> for the URL work, it would be the WHATWG, not the W3C. 2) But really
> as far as the API of URLQuery goes, that's mostly arv, TabAtkins, and
> I. 3) If you have feedback on it, better to email it :-)

The point I was making in that comment is that one thing we on TC39
might want to do is provide more collection APIs so that you don't
have to design them on the DOM side.  I'm glad that you're talking to
TC39 about the design you're doing.

[1] Item 57 in Effective JS. :)


More information about the es-discuss mailing list