Re: CSP 1.1 DOM design

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