Interfaces allow member definitions?

[Frustrated]

On Thursday, 30 January 2014 at 17:38:26 UTC, Steven
Schveighoffer wrote:
> On Thu, 30 Jan 2014 12:30:04 -0500, Frustrated 
> <c1514843 at drdrb.com> wrote:
>
>> On Thursday, 30 January 2014 at 17:11:24 UTC, Steven
>> Schveighoffer wrote:
>>> On Thu, 30 Jan 2014 11:58:15 -0500, Frustrated 
>>> <c1514843 at drdrb.com> wrote:
>>>
>>>
>>>> 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.
>>>
>>> It's simpler than that. A function is a block of code. A 
>>> vtable entry points to a block of code. Just point the vtable 
>>> entry at the block of code that is the default implementation.
>>>
>>> -Steve
>>
>> Right, this was my original point and why I thought there was
>> already entries for the interface in the vtable(since I seemed 
>> to
>> have called some function that did nothing when it should 
>> have).
>
> I think your original example should not have happened. Either 
> there was a bug in the runtime, compiler, or your memory :)
>

Well, as usual, it is almost surely user error. I can't reproduce
it so we'll just go with that.

>>
>> It seems so simple and offers some benefit(would at the very
>> least stop requiring one to implement a class every time they
>> want test a design. When programming to interfaces and using 
>> some
>> type of factory it makes even more sense.
>
> This is a misunderstanding, you still need to declare a class, 
> because an interface is not a concrete type. But if there are 
> default implementations for all the interface functions, you 
> don't need to implement any of them!
>

No, the point is, if all methods are defined, there is no need to
create the class. Why create an empty class to instantiate it
when the compiler can do it for you and you can instantiate the
interface? This is what I mean by treating the interface as a
class because for all purposes it is. (an interface is just an
abstract container but it doesn't have to be)

Again, all this could be done by the compiler internally by
creating a class to back an interface and add it to the vtable.
Instantiating the interface just returns that class. Calling a
member on the interface's object calls the member of that class,
who's body is provided in the interface definition.

I can do this now, the whole point is I don't like code
duplication! ;)

interface A
{

      void foo() { writeln("me"); }
      void bar();
}

class _A  // created internally by compiler
{
      void foo() { writeln("me"); } // added by compiler copied
from A
      void bar() { assert(0, "error"); } // added by compiler
}

A a = new A; // reinterpreted by compiler as A a = new _A;

a.foo(); // prints me
a.bar(); // asserts

e.g., all we would see is

interface A
{

      void foo() { writeln("me"); }
      void bar();
}

which is much nicer on the eyes and about half the code.


One may argue that this blurs the lines between a class an
interface but it doesn't. It can still have multiple inheritance
but easily provide a default way to deal with stuff.

Remember, the whole point of interfaces was to solve diamond
problem. They also now provide the "contract"... I'm just trying
to get them to provide the "contract" with default behavior.