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: Jeff Laing <email@hidden>
- Date: Wed, 30 Nov 2005 14:37:43 +1100
> 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.
> 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.
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. 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.
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.
If my singleton registered for notifications then sure, the cleanup via
release doesn't work, and I'm sure there are others. But thats not what I'm
asking, thats the singleton doing things to itself. I'm asking "why would
*you* retain a singleton" ?
> I'm not sure why the NSLog(), and why external retains are a problem
> if they've been properly balanced? At the time you receive the
I use GeekTool (http://projects.tynsoe.org/en/geektool/) to keep my
console.log (or is it system.log - I forget) on my desktop and you would be
amazed at the number of production tools (including Interface Builder) that
dump out all sorts of "Oh my god, how did I get here" information via
NSLog(). Personally, I think all Apple developers should be forced to use
it (GeekTool) by default.
Assuming that retain/releases are not properly balanced, the Log message
would tell me "oops, you haven't cleaned something up" and I would need to
drag out the developer tools that let you track that sort of stuff down.
> notification, you don't know who else might still legitimately be
> retaining the object, especially since AFAIK notifications aren't
> guaranteed to be in any particular order.
I agree it doesn't pin down the problem, it just highlights that the problem
exists.
_______________________________________________
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