"The last feature": overridable methods in interfaces

[Steven Schveighoffer]

On Mon, 08 Feb 2010 16:09:19 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Steven Schveighoffer wrote:
>> On Mon, 08 Feb 2010 15:13:33 -0500, Andrei Alexandrescu  
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>
>>> Steven Schveighoffer wrote:
>>>> On Mon, 08 Feb 2010 14:36:37 -0500, Andrei Alexandrescu  
>>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>>
>>>>> Don wrote:
>>>>>>  I don't understand this. How does belowTop() know how to call  
>>>>>> top()?
>>>>>
>>>>> It calls top() through the normal interface mechanism. Inside  
>>>>> belowTop(), this has Stack!T type.
>>>>  Actually, I think Don has a point here.  A virtual function (even on  
>>>> an interface) is always called with the 'this' pointer, not the  
>>>> interface pointer.
>>>
>>> That is done via an adjustment of the reference. In the case of an  
>>> interface method, no adjustment is necessary. Inside the method,  
>>> "this" has the static type of the interface and the dynamic type  
>>> whichever class implements the interface.
>>   void foo(Stack!T st)
>> {
>>   auto x = st.belowTop();
>> }
>>  OK, so if st's virtual function for belowTop points to the default  
>> implementation, there is no adjustment.  But what if the actual object  
>> *did* override the default implementation?  Does it also receive the  
>> interface pointer as 'this'?  Where does the adjustment happen?  What  
>> happens if you have a reference to the actual concrete object type?  Do  
>> you have to thunk to the correct interface to pass in the expected  
>> interface pointer?  It can't be both ways.
>
> If an object overrode the default implementation, the pointer to method  
> belowTop will point to code that does do the adjustment.

If I understand this correctly, calling such a "default implementation"  
function is different than calling a standard interface function.  And  
each entry in such an interface for a overridden method will point to a  
"pre function" that adjusts the 'this' reference before jumping to the  
real implementation.

The vtable entries of the object itself would point to a function that  
does not do the adjustment, correct?

I think all the information is available to make this work, the only issue  
I see is that a function with a default implementation artificially  
changes the ABI for that function.  Adding a default implementation  
therefore will make compiled objects incompatible, even with the same  
vtable layout.

As of today, I don't see this being a problem, since you generally only  
build static D programs.  But I can't see a huge flaw in the idea.

-Steve