Le 05/11/2012 13:57, Alex Russell a écrit :
On Mon, Nov 5, 2012 at 12:14 PM, David Bruant <[email protected]
<mailto:[email protected]>> wrote:
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".
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
