Le 05/11/2012 12:50, Alex Russell a écrit :
On Mon, Nov 5, 2012 at 10:56 AM, David Bruant <[email protected]
<mailto:[email protected]>> wrote:
Le 05/11/2012 11:32, Alex Russell a écrit :
On Mon, Nov 5, 2012 at 1:08 AM, Boris Zbarsky <[email protected]
<mailto:[email protected]>> wrote:
On 11/4/12 3:58 PM, Alex Russell wrote:
DOMString toString();
This should probably be:
stringifier;
instead (which in ES will produce a toString on the
prototype, but is more clear about the point, and might do
different things in other binding languages).
Other binding languages don't matter, but OK.
I heard Google is working on this "Dart" thing. Unless Google
redefine APIs for every single web browser capability, it will
probably need to define WebIDL bindings for Dart. But what do I
know...
You know, we should go talk to the guys who designed the Dart
DOM...oh, wait, that's me (and arv and jacobr and jmesserly)!
I wrote "every single web browser capability", not "DOM".
I agree with you about the DOM. The Dart effort (and DOM4 to some
extent) is excellent for what it did to the DOM API (great job guys!).
Yes, it's a lot of work, but if you're not taking care to create a
great API for one of your most frequently-used libraries, you're
screwing your language and your users. I posit that every language
with enough users to matter will do this exercise (JS has done so many
times over in the form of the ubiquitous library tax that slows so
many sites).
FWIW, we can still use WebIDL as a stepping stone to fix the b0rken JS
bindings. But we need to collectively stop pretending that:
1. We should be designing JS APIs though the lens of what WebIDL
can/can't do
Is anyone really doing this? WebIDL didn't exist a couple of years ago
and people were designing APIs anyways. Also, WebIDL is still in flux;
if WebIDL is limitating, just ask for a change in WebIDL. I've seen a
bunch of posts from Boris Zbarsky in that direction.
1. That there are other language consumers of WebIDL-defined DOM APIs
that both matter and will not go their own way when presented with
un-idiomatic/kludgy designs.
If you've read WebIDL recently, you've realize that only an ECMAScript
binding is defined. I'm not sure anyone pretends there is another
language consuming WebIDL.
I feel you have some misconceptions regarding WebIDL.
Perhaps there's some future world in which we decide that having an
IDL to describe API invariants is a good idea (although it doesn't do
that today to any reasonable degree), but nobody I know is clamoring
for that.
Another thing to think about is whether reportURIs should
really be an IDL array (which does NOT produce a JS array on
the JS side, so it really depends on the expected use cases).
I'll advocate for a JS array wherever we surface an array-like
collection. It's long past time that we stopped shitting on users
with ad-hoc collection types.
Arguably, ES6 symbols may give a re-birth to ad-hoc collection
types by allowing safe (uncollidable) extension of built-ins. I
think an IDL array is fine (as far as I can tell, the difference
with a regular array is just a different prototype).
That's enough to make it toxic.
I don't understand this point. I'm not 100% up-to-date on ES6 classes,
but it seems that WebIDL arrays are the equivalent of doing "class
MadeUpName extends Array{}". If that's the case, do you think extending
Array using ES6 classes is toxic as well?
David
