What's the point?

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.

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?

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.

Is that theoretical JSIDL defined anywhere, at least some of it?

(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

(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.

Are these going to be *real* JS classes (ones that can be extended by other JS objects) or continue to be magical host objects?

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.

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.

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.

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);

From JSIDL, I think coercion rules are more useful than class to put into WebIDL.  I cannot really see a net improvement from class.

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.