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
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
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
(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.
> 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 . 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.
More information about the es-discuss