Le 17/12/2012 15:56, Anne van Kesteren a écrit :
On Mon, Dec 17, 2012 at 3:39 PM, David Bruant <[email protected]> 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.
David
[1] https://gist.github.com/3918227
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
