- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Fri, 13 Sep 2013 10:53:12 -0400
- To: Anne van Kesteren <annevk@annevk.nl>
- CC: WebApps WG <public-webapps@w3.org>
On 9/13/13 10:49 AM, Anne van Kesteren wrote: > On Fri, Sep 13, 2013 at 3:22 PM, Boris Zbarsky <bzbarsky@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
Received on Friday, 13 September 2013 14:53:46 UTC