"The last feature": overridable methods in interfaces
SeeWebsiteForEmail at erdani.org
Mon Feb 8 14:17:31 PST 2010
> 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.
> I have a strong suspicion that it's exactly the same as multiple
> 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.
More information about the Digitalmars-d