- From: David Bruant <bruant.d@gmail.com>
- Date: Mon, 05 Nov 2012 13:14:02 +0100
- To: Alex Russell <slightlyoff@google.com>
- CC: Boris Zbarsky <bzbarsky@mit.edu>, public-web-security@w3.org, Webapps WG <public-webapps@w3.org>, Erik Arvidsson <arv@chromium.org>, John Messerly <jmesserly@google.com>, Jacob Richman <jacobr@google.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
- Message-ID: <5097AD8A.60109@gmail.com>
Le 05/11/2012 12:50, Alex Russell a écrit : > On Mon, Nov 5, 2012 at 10:56 AM, David Bruant <bruant.d@gmail.com > <mailto:bruant.d@gmail.com>> wrote: > > Le 05/11/2012 11:32, Alex Russell a écrit : >> On Mon, Nov 5, 2012 at 1:08 AM, Boris Zbarsky <bzbarsky@mit.edu >> <mailto:bzbarsky@mit.edu>> 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
Received on Monday, 5 November 2012 12:14:43 UTC