Returning to my favourite topic of pointers-to-methods...

Okay, so I understand why you don't want to add them in D. Then, can you do just one little thing: make it so that unary &, when used on methods, returns their position in vtable? Using this and the knowledge of internal structure of Object (I believe it's not "implementation- defined", right?), I'll do the wrapper myself.

You ask there is a problem with interfaces, well, this could be solved by only allowing & to be used on methods of class that aren't implementations of some interface (so they reside in the very first vtable)...

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a0vk3j$25i3$1@digitaldaemon.com...

> you do just one little thing: make it so that unary &, when used on methods, returns their position in vtable?

Or, even better, return it as a pointer to global function. For example, this case:

    class MyForm : Form
    {
        void Button1_OnClick(Object sender) { ... }
    }

Here, &Button1_OnClick would be of type void(*)(Object). This would
allow for better typechecking, like this:

    class ClickEvent
    {
        this(void(*handler)(Object), Object owner) { ... }
    }

    class MouseEvent
    {
        this(void(*handler)(int, int, int, int), Object owner) { ... }
    }

Of course, when it comes to calling the handler, Event takes care
of passing "this" pointer appropriately (does it go first or last BTW?).

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a0vleu$26ha$2@digitaldaemon.com...
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:a0vk3j$25i3$1@digitaldaemon.com...
>
> > you do just one little thing: make it so that unary &, when used on methods, returns their position in vtable?
>
> Or, even better, return it as a pointer to global function. For example, this case:
>
>     class MyForm : Form
>     {
>         void Button1_OnClick(Object sender) { ... }
>     }
>
> Here, &Button1_OnClick would be of type void(*)(Object). This would
> allow for better typechecking, like this:
>
>     class ClickEvent
>     {
>         this(void(*handler)(Object), Object owner) { ... }
>     }
>
>     class MouseEvent
>     {
>         this(void(*handler)(int, int, int, int), Object owner) { ... }
>     }
>
> Of course, when it comes to calling the handler, Event takes care
> of passing "this" pointer appropriately (does it go first or last BTW?).

But then you get the pointer to the real function, and it is no longer virtual. -Walter

"Walter" <walter@digitalmars.com> wrote in message news:a0vlsl$26rh$1@digitaldaemon.com...

> But then you get the pointer to the real function, and it is no longer virtual. -Walter

Absolutely. But I don't need them to be virtual! I want some way to bundle a member function to a slot. Who needs to override event handlers (like Button1_OnClick) anyhow?

Besides, if this is an issue, you could make the pointer actually be an integer defining the position of function in the vtable... but the type would still be function pointer. This is only used for type-checking anyhow...

Could you please state if method pointers (or my latest
suggestion in this thread) are or are not supported in D?
I'm sitting here and don't know what to do - hope to
get this question clearer... if you say "yes", great, if
"no", I'll use a partial solution: delegates. Anything
is better than waiting.

For an answer right now, it'll be "no". Doesn't mean it will always be that way, doesn't mean that method pointers are a bad idea, I just am buried with work and I can't address it now.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a1hql4$1gae$1@digitaldaemon.com...
> Could you please state if method pointers (or my latest
> suggestion in this thread) are or are not supported in D?
> I'm sitting here and don't know what to do - hope to
> get this question clearer... if you say "yes", great, if
> "no", I'll use a partial solution: delegates. Anything
> is better than waiting.
>
>