Re: CSP 1.1 DOM design

On Mon, Nov 5, 2012 at 12:14 PM, David Bruant <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> 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> 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? 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 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?
>

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.


> 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.


> 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"? ;-)

>
>    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.


> 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
>