URLs / subclassing JavaScript

Alex Russell slightlyoff at google.com
Tue Dec 18 07:32:32 PST 2012


hey Anne, Sam! Comments inline:

On Monday, December 17, 2012, Sam Tobin-Hochstadt wrote:

> On Mon, Dec 17, 2012 at 9:19 AM, Anne van Kesteren <annevk at annevk.nl<javascript:;>>
> 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.


I don't think that's wise. Rafael (cc'd) can explain why in much more
detail, but the gist of it is:

Object.observe() is a notification, not interception, mechanism. Where we
need to stratify an intercept, ES 6 Proxies are the mechanism we should
lean on, but in the main, we should ALWAYS seek to avoid using them. That
is to say, if we must do magic (use proxies), we must do magic; however we
should only arrive there after exhausting all other routes; both on the JS
and DOM sides.


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

In the shorter term, your constructor can vend a Proxy (using the mechanism
Allen et. al. have devised on es-discuss and here recently).


> > I guess the problems here are that a) there's no MultiMap b) there's
> > no types


The lack of typing strikes me as something we can use de-sugaring in
WebIDL-generated JS to enforce. I.e., generate the JS that you'd need for
type checking:

Imagine we have IDL for a function:

// IDL
void takesOnlyStrings(DOMString arg, ...);

// JS de-sugaring
function takesOnlyStrings(...args) {
  if(!args.every(function(i) { return typeof i == "string"; })) {
    throw new TypeError("...");
  }
  // implementation goes here
}

But if we consider a JS-only world, the typing discussion becomes a bit
less obvious. The semantic I'd instead expect in most libraries is for them
to call .toString() on the argument in question, not to reject with an
error.

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

Agreed on both counts.


> [1] Item 57 in Effective JS. :)
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <javascript:;>
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121218/61485783/attachment.html>


More information about the es-discuss mailing list