December 05, 2001 About Events (Pointer to Funcions) | ||||
|---|---|---|---|---|
| ||||
The Delphi Event approach has its drawbacks.
The major one is the dificulty of making cascating events :
type
TEvent = procedure of object;
TMyObj = class(TAnyClass)
private
FOnEvent : TEventProc.
published
property Event : TEvent read FOnEvent write FOnEvent;
end;
var MyObj : TMyObj;
...
procedure ProcEvent;
begin
...
end;
...
begin
MyObj.Event := ProcEvent.
end.
Until now nothing new. But try assign a new event for any object without
droping the last.
Think in another object TAnotherObj wich know TMyObj and need add a new
action when event is fired.
Always the programmer must code the cascating :
type
TAnotherObj = class(TAnyoneObj)
private
FEventCasc : TEvent
...
procedure TAnotherObj.AssignEvent(Obj : TMyObj).
begin
FEventCasc := Obj.OnEvent;
Obj.OnEvent := Self.FireEvent;
end;
procedure TAnotherObj.FireEvent;
begin
if FEventCasc <> nil then
FEvent; // Fire the old event
...
end;
The problem is the endless repetition of this problem in all Delphi
components and framewoks.
Sometime can we think in a better solution for this problem.
If you are thinking in adding event like mecanism for D is important to
think in event cascating too.
"Pavel Minayev" <evilone@omen.ru> wrote in message news:9uidvf$2212$1@digitaldaemon.com...
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;
| ||||
December 06, 2001 Re: About Events (Pointer to Funcions) | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Juarez Rudsatz | "Juarez Rudsatz" <juarez@mpsinf.com.br> wrote in message news:9um1r4$1oeq$1@digitaldaemon.com... > The problem is the endless repetition of this problem in all Delphi > components and framewoks. > Sometime can we think in a better solution for this problem. > If you are thinking in adding event like mecanism for D is important to > think in event cascating too. IMHO the big problem here is that unlimited-depth cascading requires growing stack, which would be much slower and memory-consuming compared to a simple pair of pointers. Cascading is not always that necessary, in most cases you just want to set a handler to be called when a button is clicked etc... if it'd really to become a part of a language, it should be a separate type of the pointer, IMHO. | |||
Copyright © 1999-2021 by the D Language Foundation
Permalink
Reply