delegate cannot handle polymorphism?

[Steven Schveighoffer]

On Mon, 27 Jun 2011 22:23:32 -0400, Nub Public <nubpublic at gmail.com> wrote:


> I have to disagree on this.
> Member function pointers are useful in many event handling systems.  
> Imagine a signal and slot system. To register a member function as a  
> slot, the most direct and intuitive way is to take a member function  
> pointer. In c++0x and boost, <function>, <functional> and related  
> libraries all work with member function pointers.
>
> My premise is simple: a virtual function should always be resolved by  
> the dynamic identity of the object, regardless of whether it is called  
> directly or through a function pointer.

This can be had using delegates, but it's not straightforward, you need to  
do a little bit of extra work.

For example, if you did this:

class A
{
    final void callFoo() { foo(); }
    void foo() {writeln("A");}
}

class B : A
{
    void foo() {writeln("B");}
}

A delegate to callFoo would do polymorphism, even when you change the  
context pointer (to a compatible instance).

Note that it is highly unusual to change anything about a delegate, as  
type checking the context pointer is out the window.  In fact, it is the  
property of delegates which makes them so useful -- because you don't have  
to care what the type of the context pointer is, the delegate's type does  
not depend on it.

> Perhaps the contextptr of D delegate cannot do this because it can refer  
> to the enclosing context besides an object. But I'd love it for D to  
> have the functionality of a truly polymorhic member function pointer.  
> Maybe the restrictions on the keyword "function" can be relaxed to work  
> with such a pointer?

The easiest thing to do is the suggestion from Michel Fortin -- create a  
function/delegate that accepts the base type.  This is much safer as  
well.  I would be highly suspect of code that alters any delegate  
components.

-Steve