realbasic-nug
[Top] [All Lists]

Re: Stupid question: instantiating classes at runtime--what about method

To: REALbasic NUG <realbasic-nug at lists dot realsoftware dot com>
Subject: Re: Stupid question: instantiating classes at runtime--what about methods
From: Norman Palardy <npalardy at great-white-software dot com>
Date: Mon, 31 Dec 2007 11:13:10 -0700
Delivered-to: listarchive at realsoftware dot com
Delivered-to: realbasic-nug at lists dot realsoftware dot com
References: <45a1b53e0712301802i69eef3asc37b33d29ea054be at mail dot gmail dot com> <490E7959-03F7-480F-9ABD-9D64351B0D7B at declareSub dot com>
On 31-Dec-07, at 8:53 AM, Charles Yeomans wrote:

> Okay, here is an example.  To a module, add a delegate Sub
> TimerActionHandler(t as Timer).  Next, define a subclass Delegating
> Timer as Timer.  Add a public property ActionHandler as
> TimerActionHandler.  Then implement its Action event handler as  
> follows:
>
> Sub Action()
>    if me.ActionHandler <> nil then
>      me.ActionHandler.Invoke me
>    end if
> End Sub
>
>
> You now have a timer that allows you to plug in behavior at runtime.
>
>
> My column in the upcoming issue of REALbasic Developer offers a few
> brief examples of how one might use delegates.  Also, my update to
> Sparkle for REALbasic uses delegates to handle some events; you might
> take a look at that.
>
> Charles Yeomans

Just out of curiosity what would prompt you to use a delegate instead  
of an interface and various implementors ?
I realize this would be a pretty simple interface (1 method) but at  
what point do you prefer a delegate over a simple interface ?
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>


<Prev in Thread] Current Thread [Next in Thread>