URLs / subclassing JavaScript

David Bruant bruant.d at gmail.com
Mon Dec 17 07:34:39 PST 2012

Le 17/12/2012 15:56, Anne van Kesteren a écrit :
> On Mon, Dec 17, 2012 at 3:39 PM, David Bruant <bruant.d at gmail.com> wrote:
>> Which part of the platform needs a sync Object.observe?
> (Thanks for the reply.)
Thanks for your post.

> I think nothing does per se, but it might make
> manner more convenient.
I understand. It however doesn't necessarily make it a good candidate 
for ECMAScript (just as a reminder, I'm just someone sending emails; I 
don't have any decision power among TC39, so that's just my opinion).
I feel that browser APIs need some sort of cross-API tools. Sync 
Object.observe, MultiMap, Promises, maybe even Streams as examples. I 
don't know if these cross-API things are necessarily good candidates for 
ECMAScript, but I agree it's worth discussing.

>> I don't understand what you mean by "types". And I also don't understand
>> what you can't implement in pure ES6 in what you've described.
> By types I mean e.g. constraining set() to just accept strings.
> There's not a problem implementing this in ES6, I'm just wondering
> what is considered better here. I'm getting kinda tired of the "IDL is
> terrible and outside TC39 people design terrible APIs" sentiment
:-) I guess this deserves a long answer.
I think IDL is a necessary and important tool. At a TestTheWebForward 
event, I've seen a test suite based on a WebIDL parser and I thought it 
was one of the most brilliant idea regarding testing the ECMAScript 
representation of browser APIs. If that was the only reason for WebIDL 
to exist, that'd be enough to make WebIDL a good idea.
Now, one problem that Alex Russel noted elsewhere is that some people 
who're used to C++ interfaces use WebIDL as a guideline to define new 
APIs. The bad use of the WebIDL tool is a problem. Not the tool in itself.

I don't necessarily think that TC39 does everything perfectly when it 
comes to APIs (second argument of Object.create someone?); I have myself 
provided lots of feedback on APIs for ES6. TC39 has proven to be 
receptive to feedback, for sure. I have much less experience with other 
standard bodies, so I couldn't compare.

> so I figured I'd just go and ask since this is a new API and can be
> amended.
That's an initiative I encourage, because es-discuss (which contains 
many more people than TC39) is a cross-road of a lot of people using 
JavaScript, a good share caring a lot about clean, composable APIs.

If looking for advice on API design, I would also recommend asking the 
Node.js folks. Some read es-discuss. I don't know how to contact them 
for advice on JS API design, but I find most of their work on JavaScript 
APIs admirable.
(I look forward to some interoperability between Node and web browser 
APIs, but I'm a dreamer)

>> I feel there are 2 different goals:
>> * Being able at all to implement browser APIs in ECMAScript (which is close
>> to being possible with Proxies. document.all being an exception).
>> * Being able to conveniently implement browser APIs in ECMAScript (which may
>> require the addition of a MultiMap) which is up for debate.
> I feel there's another one too, "make it JavaScript-y", though this is
> never described much in detail, although from what I got so far using
> Proxies is not considered good practice. That's why the URLQuery API
> has no getter/setter but instead has methods like get() and set().
I agree that proxies don't seem to be a good fit to emulate MultiMaps. 
Proxies are more like maps [1]. It would be awkward to distinguish 
append and set with proxies.
I think I also agree to reduce the use of proxies magics as much as 
possible. I was citing proxies, because they're a major tool in closing 
the gap that separates ECMAScript and the platform APIs magic.


[1] https://gist.github.com/3918227

More information about the es-discuss mailing list