On Thursday, 30 January 2014 at 15:28:24 UTC, Steven
Schveighoffer wrote:
On Thu, 30 Jan 2014 09:31:05 -0500, Frustrated
<c1514...@drdrb.com> wrote:
I'm not asking about a work around but if what I am talking
about
can actually be done(does the vtable support this or can made
to
support it?)
Yes. Interfaces have no concrete vtable. Only classes do. A
concrete class can decide what the vtable has in it, and if you
had a "default" implementation, the compiler could stick that
in there. Note that the default implementation only can call
other member functions within the interface or module-level
functions, interfaces cannot access any derived data or members.
Whether such a change would be accepted? No clue.
-Steve
Basically I see no reason why the compiler can't treat the
interface as a class and allow "default" methods. (it would have
to allow multiple inheritance on that class though)
All it would do is make it easy to provide a default
implementation(more of a static implementation but allows it to
be overriden, which makes it useful).
For example, when creating a design you would no longer have to
specifically create a corresponding class to use for the
interface. You could just provide some default implementations of
everything(throw errors, write stuff, etc...)
I think it would be probably rather easy to do by extending the
vtable to have one lower level, the interface methods, which, in
fact, could use this(so you could have a this in them but only
reference other members of the interface).
Essentially what it boils down to is treating interfaces like
classes that have no fields). To avoid the diamond problem simply
always choose the method that is not from the interface(since it
is "default"), which is done naturally with the vtable.
Of course, maybe this just creates the diamond problem for
interfaces: "which default implementation to use"... which I'm
not sure if it's a problem?
