On 9/13/13 10:49 AM, Anne van Kesteren wrote:
On Fri, Sep 13, 2013 at 3:22 PM, Boris Zbarsky <bzbar...@mit.edu> wrote:
In any case, my real questions revolve around generic vs branded methods and
whatnot, which are not covered by those two bugs.
I think they should be generic
OK, fwiw I think I agree. The next question is whether they should be
generic in the elements of the collection or not too.
Because IDL doesn't really deal well with this.constructor-type stuff
and generic methods.
Sure, but that's something to fix in IDL.
Updating IDL to make that work have proper
terminology hooks is fine for me too.
Good. That's what I'd like to see, and what should imo happen on
public-script-coord.
The IDL specification style is a lot less error-prone to implement for
non-JS-engine-hackers than the ES specification style, for what it's worth,
since it allows implementors to work with objects that have sane behavior in
the implementation language, not whatever weird behavior the js engine API
imposes...
TC39 and like-minded people are pushing in the direction of the
platform being mostly a JavaScript library which would indeed give you
exactly those problems...
Why?
There is no reason we can't have macros for commonly used ES-style
patterns that people can use by reference in specs. That's supposed to
be the purpose of WebIDL.
I'm not really sure how to reconcile those two views.
Like I just said above.
Anything other than these aspects?
Not sure what you're asking.
-Boris
