On Dec 31, 2007, at 1:59 AM, Eric Williams wrote:
> Hello list -
>
> I have a situation which, oddly enough, seems to call for a circular
> reference, and I wanted some feedback on whether it's a good idea or
> not.
>
> The app needs to send it self a slightly delayed message - say, after
> a few seconds. I'm planning to deploy a Timer that calls back to an
> object's HandleTimedAction method. It's possible that several of
> these little timers could be necessary at once, and I don't want to
> keep track of them if I don't have to.
>
> Can I set up the timer with a property "myself as Timer" to make sure
> it doesn't go out of scope? Then, in the Timer's Action event, I can
> set the myself property to nil and it should just evaporate after the
> event ends (because no other object will hold a reference to it).
>
> Does anybody see any problem with this approach? Incidentally, I'm
> considering the circular reference setup to avoid a potential stack
> overflow. :)
This would work, and it's not an unreasonable approach. Indeed, one
needs to do something similar with listener sockets created by a
ServerSocket. Another way to keep references to the Timers would be
to store them in a shared property of your Timer subclass. This would
make it possible, for example, to provide a way to get references to
the timers if another object needs to turn them off.
Charles Yeomans
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|