23225 2013-09-12 13:22:56 +0000 Let's start using class, not interface 2017-12-06 10:30:33 +0000 1 1 1 Unclassified WebAppsWG WebIDL unspecified PC All RESOLVED MOVED P2 normal --- 1 annevk cam arun bruant.d bugs bzbarsky jonas marcosscaceres mike public-script-coord robin w3c zcorpan public-webapps-bugzilla oldest_to_newest 93289 0 annevk 2013-09-12 13:22:56 +0000 We could keep interface around for where we now use [NoInterfaceObject] I suppose. Maybe also introduce "extends" rather than ":". 93290 1 zcorpan 2013-09-12 14:36:42 +0000 What's the point? 93292 2 annevk 2013-09-12 14:53:05 +0000 Communicate intent better over the long term. We're defining what JavaScript calls classes, naming them something else makes specifications harder to read, which is bad for developers. It might also give people writing specifications a better clue as to what they have to do. 93293 3 arun 2013-09-12 15:02:37 +0000 Current editor's draft of WebIDL still sticks to interface; is this a JSIDL proposal, and if so, can you include a link to the right conversation about this? 93294 4 annevk 2013-09-12 15:07:13 +0000 This is the conversation. I think rather than dropping IDL wholesale, it'll be easier to improve it incrementally in the direction of something that better matches a theoretical JSIDL. 93297 5 bugs 2013-09-12 16:13:54 +0000 Is that theoretical JSIDL defined anywhere, at least some of it? 93298 6 w3c 2013-09-12 16:21:44 +0000 (In reply to Olli Pettay from comment #5) > Is that theoretical JSIDL defined anywhere, at least some of it? http://w3ctag.github.io/jsidl/jsidl.html 93340 7 robin 2013-09-13 09:12:02 +0000 (In reply to Anne from comment #4) > This is the conversation. I think rather than dropping IDL wholesale, it'll > be easier to improve it incrementally in the direction of something that > better matches a theoretical JSIDL. I'm not entirely convinced that incremental improvement is the best strategy in this specific case. A lot of drafts out there are using WebIDL. If we do incremental improvements by removing stuff, we'll break them (they'll get fixed over time, but it won't be pleasant). If we do it by keeping existing constructs alive, we'll end up with a crufty language. Not everything needs the same upgrading strategies as the web. If we get something new and nicer, people can switch over wholesale. 93346 8 marcosscaceres 2013-09-13 11:19:26 +0000 Are these going to be *real* JS classes (ones that can be extended by other JS objects) or continue to be magical host objects? 93350 9 annevk 2013-09-13 13:13:45 +0000 Marcos, host objects is a thing of the past since ES5. Robin, maybe. If proposed changes have implementation impact (and I'm sure some will), gradual change seems easier to cope with given that IDL is already implemented. I think attacking this on both fronts is what will get us to better JavaScript. Slowly fixing IDL and trying to re-imagine IDL. 93353 10 bugs 2013-09-13 15:26:37 +0000 What would Foo implements SomeClass mean in the new JS terms? That at least sounds odd, and I'd expect SomeClass to be actually an interface, not a class. 93354 11 annevk 2013-09-13 15:54:08 +0000 I would expect that to be a straight copy of the members, just as it is now. I think we want to keep interface for that and that would mean [NoInterfaceObject] could go away. 93358 12 jonas 2013-09-13 16:09:00 +0000 I don't think we should allow X implements SomeClass; we should only allow X implements SomeInterface; I.e. classes should always have "interface objects" (aka "constructor functions") and interfaces never have them. And only classes show up on the prototype chain (with exception for weirdness on the global scope). Interfaces would only be used as a construct for described shared APIs and for when those shared interfaces are required in function arguments. I.e. interfaces would only be used for X implements SomeInterface; and void fooFunction(SomeInterface arg); 93361 13 arun 2013-09-13 16:53:28 +0000 From JSIDL, I think coercion rules are more useful than class to put into WebIDL. I cannot really see a net improvement from class. 128990 14 annevk 2017-12-06 10:30:33 +0000 Now that we have mixins the implements thing is no longer a concern, but also, let's track this in https://github.com/heycam/webidl/issues/485.