Bug 23225 - Let's start using class, not interface
Let's start using class, not interface
Status: NEW
Product: WebAppsWG
Classification: Unclassified
Component: WebIDL
unspecified
PC All
: P2 normal
: ---
Assigned To: Cameron McCormack
public-webapps-bugzilla
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-12 13:22 UTC by Anne
Modified: 2013-09-16 03:19 UTC (History)
11 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Anne 2013-09-12 13:22:56 UTC
We could keep interface around for where we now use [NoInterfaceObject] I suppose. Maybe also introduce "extends" rather than ":".
Comment 1 Simon Pieters 2013-09-12 14:36:42 UTC
What's the point?
Comment 2 Anne 2013-09-12 14:53:05 UTC
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.
Comment 3 Arun 2013-09-12 15:02:37 UTC
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?
Comment 4 Anne 2013-09-12 15:07:13 UTC
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.
Comment 5 Olli Pettay 2013-09-12 16:13:54 UTC
Is that theoretical JSIDL defined anywhere, at least some of it?
Comment 6 Marcos Caceres 2013-09-12 16:21:44 UTC
(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
Comment 7 Robin Berjon 2013-09-13 09:12:02 UTC
(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.
Comment 8 Marcos Caceres 2013-09-13 11:19:26 UTC
Are these going to be *real* JS classes (ones that can be extended by other JS objects) or continue to be magical host objects?
Comment 9 Anne 2013-09-13 13:13:45 UTC
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.
Comment 10 Olli Pettay 2013-09-13 15:26:37 UTC
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.
Comment 11 Anne 2013-09-13 15:54:08 UTC
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.
Comment 12 Jonas Sicking 2013-09-13 16:09:00 UTC
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);
Comment 13 Arun 2013-09-13 16:53:28 UTC
From JSIDL, I think coercion rules are more useful than class to put into WebIDL.  I cannot really see a net improvement from class.