We could keep interface around for where we now use [NoInterfaceObject] I suppose. Maybe also introduce "extends" rather than ":".
What's the point?
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?
(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.
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;
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.