"The last feature": overridable methods in interfaces

[Andrei Alexandrescu]

Don 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.
>>
>> -Steve
> 
> I have a strong suspicion that it's exactly the same as multiple 
> inheritance.
> I thought about this quite a bit a year ago, and initially I thought 
> that having no data members made it OK. But it's deceptive.
> Virtual member functions are still a problem. I think you can only have 
> final functions.

I think it's only data. The problem is that you end up storing multiple 
copies of the same interface object inside the final object. As long as 
the per-interface state is compiler-maintained and immutable, you should 
be in good shape.

Andrei