Re: CSP 1.1 DOM design

Le 05/11/2012 13:57, Alex Russell a écrit :
> On Mon, Nov 5, 2012 at 12:14 PM, David Bruant <bruant.d@gmail.com 
> <mailto:bruant.d@gmail.com>> wrote:
>
>     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".
>
>
> WebIDL is about DOM. Does it even have other users?
I think Anne pointed a potential misunderstanding in his message. I 
personally use "DOM" for what it literally stands for. For the rest, I 
say "browser capability" or "browser APIs" or "web APIs".
I read "WebIDL is about DOM" as a non-sense with my definition, but 
understanding that we have a different definition, it makes more sense.

> If you don't expose an API from a C++ impl to a more dynamic host 
> language, it doesn't make sense. To the extent that "DOM" is "C++ 
> objects vended to dynamic languages", yes, I maintain that every API 
> should be re-cast in terms of language-native idioms. WebIDL gets you 
> part of the way there for JS (and formerly for Java). But not the 
> whole way. When it prevents improvements (as it so often does), it's a 
> bug and not a feature.
I largely agree. Now, it just means that WebIDL needs to be improved.

>>     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?
>
>
>
> Part of my job is reviewing this sort of proposal and let me assure 
> you that /everyone/ does this. IDL /is handy. /More to the point, it's 
> the language of the specs we have now, and the default mode for 
> writing new ones is "copy/paste some IDL from another spec that looks 
> close to what I need and then hack away until it's close". This M.O. 
> is exacerbated by the reality that most of the folks writing these 
> specs are C++ hackers, not JS developers. For many, WebIDL becomes a 
> safety blanket that keeps them from having to ever think about the 
> operational JS semantics or be confronted with the mismatches.
Interesting. I wasn't aware of that.
Any idea as to how to improve the state of things? It seems to be much 
more a human problem than a WebIDL problem. Even if WebIDL improves, 
people will likely still do the copy/paste dance, no?

>     WebIDL didn't exist a couple of years ago and people were
>     designing APIs anyways.
>
>
> ...in IDL. WebIDL is descended from MIDL/XPIDL which is descended from 
> CORBA IDL. WebIDL is merely a compatible subset + JS-leaning superset.
The WebIDL defines an ECMAScript binding and that's a huge step forward. 
DOM2 ECMAScript bindings is how I discovered that specs really are made 
by human beings and are subject to being incomplete or inaccurate.
I agree WebIDL has limitations, but it's going in the right direction, I 
feel.

>     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.
>
>
> Heh. Who do you think advocated for DOM prototypes in the right 
> locations? Or has been continuiously advocating that DOM designs not 
> use create* but instead lean on "new"? ;-)
I'm aware of your work in this field. Your QCon London 2012 talk [1] 
shows where you want to go to and it's promising. I was not trying to 
say that you haven't done anything, but that the solution is to improve 
WebIDL (regardless of how much things have gotten better already).
Also, as I said above, it seems that the problem is not that much in 
WebIDL as a language, but rather WebIDL-as-people-use-it and I'm not 
sure WebIDL as a language can change people habit.

Also, I'm not sure asking C++ hackers to directly define JS interfaces 
would yield fantastic result either (we know how not interoperable are 
browser APIs in terms of their ECMAScript bindings). At least, defining 
WebIDL interfaces guarantees some consistency and interoperability. It's 
not enough, but that's a good start.

>>      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.
>
>
> Also my doing from TPAC 2011.
>
>     I'm not sure anyone pretends there is another language consuming
>     WebIDL.
>
>
> Your tried to.
No. Please read more carefully. "Unless Google redefine APIs for every 
single web browser capability, it will probably need to define WebIDL 
bindings for Dart."
I wrote "unless", meaning that Dart can avoid WebIDL and I also wrote 
"will probably". I never said or tried to pretend that other languages 
do (present tense) consume WebIDL as you suggested.

(I'm really interested in your opinion to the last point below)
>>
>>
>>>         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?
I'd love to have an answer to this point.

David

[1] http://www.infoq.com/presentations/The-Future-Is-Layered