Re: Is Apple's singleton sample code correct?
Re: Is Apple's singleton sample code correct?
- Subject: Re: Is Apple's singleton sample code correct?
- From: Andy Lee <email@hidden>
- Date: Wed, 30 Nov 2005 02:01:43 -0500
On Nov 29, 2005, at 10:37 PM, Jeff Laing wrote:
One thing that just occurred to me -- if you take the app delegate
approach, you should call a *class* method to do the cleanup,
to deal
I think the suggestion of a class method to do the cleanup is an
excellent
one - it does, however, call into question whether you need a
singleton
*instance* at all - make all singleton methods class methods and be
done
with it. The only reason I can think of is to allow you to
register for
notifications from that object.
Your singleton class might be a subclass of some other non-singleton
class. For example, NSOpenPanel is a descendant of NSWindow.
What if your object is in a retain
cycle? Then -release won't by itself ever call -dealloc. You need
some other method whose job it is to break the cycle.
I'm not sure what you mean by "retain cycle". If you mean that
under some
circumstance, my singleton retained some object that also retained the
singleton, then yes, I can see that that will cause grief. But thats a
pattern I'd never consciously consider.
Yes, that's what I meant. Probably not an issue 99% of the time. I
was putting it out there as a theoretical possibility.
Frankly, I'm a bit confused as to why people think that singletons
are going
to be retain'd anyway - I can't think of any scenario where *I*
would do
such a thing, but I'm not an expert by any means.
You know, retaining and releasing singletons like regular objects
made sense for a bit there, but come to think of it I would feel a
little strange doing that. Maybe if I thought more about it I would
change my mind.
Thinking more about the resource cleanup issue -- I'm still not sure
when I'd use the "internal" cleanup approach (singleton listens for
end-of-app notification) and when I'd use an app delegate method. I
prefer the latter, because I am biased against using notifications
unless they're the only way to do something. Either way:
* I would have a -doCleanUp instance method (and possibly a
+cleanUpSharedInstance class method that calls it) that renders the
object unusable, so it's safe to call more than once.
* At end-of-app I would call -doCleanUp (perhaps by way of
+cleanUpSharedInstance) instead of -release, because no matter how
well releases and retains are balanced, you never know when somebody
might do [NSApp terminate:nil]. At the moment that happens, you
might not have gotten around to all the releases needed to unwind all
the retains on your object.
* I would add a call to -doCleanUp in -dealloc, because if for some
reason you do find yourself deallocating the object, you certainly
want it to clean up after itself.
Can someone give a real
example where my application code might want to *retain* a
singleton, given
that you can always get back to it via the +sharedInstance method
anyway, so
holding on to the pointer seems like a waste.
You might not retain it explicitly, but you might put it into an
NSArray.
Yes, "registering for notifications from this guy" counts - the
notification
controller is a singleton in its own right, and I haven't fully
considered
what a "retain cycle" between two singletons might mean... - and
I'd have to
wonder what sort of singleton I'd written that did a retain on the
notification controller.
I believe the notification controller does not retain its registered
observers, precisely to avoid retain cycles. This is why you must
remember to unregister the notification in your object's -dealloc
method -- otherwise you'll have a dangling object pointer and your
app will crash.
--Andy
_______________________________________________
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