Re: How To Design A Queue of Messages?
Re: How To Design A Queue of Messages?
- Subject: Re: How To Design A Queue of Messages?
- From: Andreas Mayer <email@hidden>
- Date: Sun, 11 Sep 2005 03:16:01 +0200
Am 11.09.2005 um 01:27 Uhr schrieb j o a r:
My point is that in most cases (certainly not all, but probably
most) I doubt that you still want to send the message to that
object if the message queue is the only one retaining it.
I don't see why one case would be more probable than the other. IMHO
we'd need to know more about the problem to decide this.
I would not mind so much that you retain the enqueued objects if
you allow the owner not only the ability to enqueue, but also to
dequeue an object at any time.
If I didn't miss anything significant (it's quite late already here
in Germany) it's more that you *need* the ability to dequeue objects
if you don't want to retain them. Anything else might lead to
unexpected behaviour. AFAIK there is no way to find out if an object
(pointer) is still valid before sending a message to it. Even if you
catch exceptions you might accidentally send the message to some
other object that happened to get stored at the same memory location
as the old one. Not good.
That said, if you have that ability, then there really is little
use in retaining the enqueued objects in the first place.
I agree that it might not be necessary to retain the target in
certain conditions. But since it's more complicated to store it in a
collection *without* retaining it, I'd still go with my solution. I'm
sooo lazy ... :)
Of course there are situations where you absolutely don't want to
retain an object to avoid retain cycles; like delegation where often
the delegate knows about (i.e. retains) it's delegating object. But
this rule does not seem to apply here.
Andreas
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden