Been there, done that, in Pascal and C.  Interfacing to Windows User.  That just brings us back around to how to ease the passing of control back into a real actual object, the transmission of the this pointer has to be done somehow, and that just makes the programmer write forwarding functions with an extra object pointer parameter.

It can be argued that anything beyond the goto, test, and addition and negation is not "necessary" because we can build it ourselves from more primitive tools.  I don't want to have to build language tools to be able to get basic work done.  You'd think that a language designed today would function to make our lives easier.  I guess some kind of a member function pointer bundled with a this pointer would be a good enough replacement, if that is any less problematic.  Callbacks to objects is the main goal here I think.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:9ufg0t$2i1n$1@digitaldaemon.com...
>
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:9ucvsu$2u60$1@digitaldaemon.com...
> > Since D doesn't have macroses, it would be hard to define
> > a simple syntax for message maps. Pointers to members
> > are not supported. If I want to write a GUI library for
> > D, what other ways could I use then? WndProc and switch()
> > (aka back to the WinAPI days)? nah, totally ditches the
> > idea... anything else?
>
> What you could do is create an array of function pointers, indexed by the message number. A default one is provided by the gui library. You could write an associative array that contains just the messages you want to dispatch on. So, you test your local associative array, if it's there, dispatch. Otherwise,  use the default array, and dispatch to that one.
>
> Member function pointers are not necessary, just use a static member function.

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:9ufhqn$2jsd$1@digitaldaemon.com...
> Been there, done that, in Pascal and C.  Interfacing to Windows User.
That
> just brings us back around to how to ease the passing of control back into
a
> real actual object, the transmission of the this pointer has to be done somehow, and that just makes the programmer write forwarding functions
with
> an extra object pointer parameter.

Exactly!

Suppose we have an MDI application. In this case, you'd probably want each event to be handled by the appropriate object, associated with the child window, not by a static function shared by all objects. This is just an additional headache for the user of the library, since there are no macroses to simplify it.

> It can be argued that anything beyond the goto, test, and addition and negation is not "necessary" because we can build it ourselves from more primitive tools.  I don't want to have to build language tools to be able
to
> get basic work done.  You'd think that a language designed today would function to make our lives easier.  I guess some kind of a member function pointer bundled with a this pointer would be a good enough replacement, if that is any less problematic.  Callbacks to objects is the main goal here
I
> think.

Yes. Since window is represented by an object of a specific class, and there can be several objects of that class, each window should handle its events separately, without additional layers (that have to be manually coded by the end-user!) like static functions.

I can't really understand what's bad with the idea? What are the arguments against having it in D?

Walter wrote:

> C:
>     int (*fp)(args);    // ugly, but servicable
>
> D:
>     int (*)(args) fp;    // ??
>     int (args)* fp;    // ?? arrgh

A couple of other brainstorms:

int (*function)(args) fp1,fp2;  // requires new keyword 'function'
int func-ptr(args) fp1,fp2;   // requires new keyword 'func-ptr'
int (* fp1,fp2)(args);   // really ugly :(

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Pavel Minayev wrote:

> ...
> And for pointers to methods, I'd suggest
> the following:
> 
>     int.(args) mp;
>...


I assume that in a real example the args would be spelled out? How do you feel one should list a method that required a method argument?
  int.(.op(int.val1, float.val2) int.val1, float.val2) theFunc;
Perhaps?

"Pavel Minayev" <evilone@omen.ru> wrote in message news:9ug6ai$815$1@digitaldaemon.com...
> I can't really understand what's bad with the idea? What are the arguments against having it in D?

Member function pointers are confusing (to me, anyway), and there's some significant complexity involved with getting them implemented right.

"Walter" <walter@digitalmars.com> wrote in message news:9uhjh9$1fhs$5@digitaldaemon.com...

> "Pavel Minayev" <evilone@omen.ru> wrote in message news:9ug6ai$815$1@digitaldaemon.com...
> > I can't really understand what's bad with the idea? What are the arguments against having it in D?
>
> Member function pointers are confusing (to me, anyway), and there's some

I agree that _C++_ method pointers are confusing. But what's wrong with Delphi-like ones that I propose? In fact, what they allow is to treat methods just like you treat global functions when dealing with callbacks. What's confusing in it?

> significant complexity involved with getting them implemented right.

Not sure what it can be... could you give an example?

BTW due to the fact I needed them badly and C++ don't have them, I've implemented method pointers using templated class and some hacks... and the code was quite small.

"Charles Hixson" <charleshixsn@earthlink.net> wrote in message news:3C0BF296.6010808@earthlink.net...

> I assume that in a real example the args would be spelled out?
> How do you feel one should list a method that required a method
> argument?
>    int.(.op(int.val1, float.val2) int.val1, float.val2) theFunc;

    int.(int.(int) method1, void.(float, float), char[]) theFunc;

Dot should always go to the right. Or to the left - whichever you prefer =)

"Pavel Minayev" <evilone@omen.ru> wrote in message news:9uhsjq$1lb3$1@digitaldaemon.com...
> > significant complexity involved with getting them implemented right.
> Not sure what it can be... could you give an example?

You have to generate things like thunks. Ugh.


> BTW due to the fact I needed them badly and C++ don't have them, I've implemented method pointers using templated class and some hacks... and the code was quite small.

But C++ does have pointers to member functions.

Russ Lewis a écrit :

> Walter wrote:
>
> > C:
> >     int (*fp)(args);    // ugly, but servicable
> >
> > D:
> >     int (*)(args) fp;    // ??
> >     int (args)* fp;    // ?? arrgh
>
> A couple of other brainstorms:
>
> int (*function)(args) fp1,fp2;  // requires new keyword 'function'
> int func-ptr(args) fp1,fp2;   // requires new keyword 'func-ptr'
> int (* fp1,fp2)(args);   // really ugly :(
>

int function(args)* fp1,fp2;    // requires new keyword 'function'
                                            //pointed type is defined
before '*'
Roland

"Walter" <walter@digitalmars.com> wrote in message news:9ui1i8$1q67$1@digitaldaemon.com...

> But C++ does have pointers to member functions.

I've probably explained the thing badly.

Yes, C++ has pointers to methods. However, they point
to method of some _class_ rather than to method of some
_object_. These are very different things. Of course,
you can store pointer to object elsewhere, but not
only it looks clumsy from the POV of end-user, there
is also a stupid limitation of method belonging to
exact given class, not even its child classes - and no
workaround for the problem. Such pointers are completely
useless in context of GUI library:

    void (CForm::*OnClick)(int x, y);
    ...
    class CMyForm: public CForm
    {
        public: void Click(int x, y);
    } MyForm;
    OnClick = CMyForm::Click;    // oops, won't work!

On other hand, Delphi pointers do point to method of
one concrete object, and they absolutely don't care
of its class - they simply treat method as a function
which has a context "this" pointer associated with it:

    var
        OnClick: procedure(x,y: integer) of object;
    ...
    type
        TMyForm = class(TForm);
            public procedure Click(x,y: integer);
        end;
    var
        MyForm: TMyForm;
    begin
        OnClick := MyForm.Click;    // everything's fine
    end;