• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Is Apple's singleton sample code correct?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


References: 
 >RE: Is Apple's singleton sample code correct? (From: Jeff Laing <email@hidden>)

  • Prev by Date: Warnings that won't go away
  • Next by Date: Re: Warnings that won't go away
  • Previous by thread: Re: Is Apple's singleton sample code correct?
  • Next by thread: RE: Is Apple's singleton sample code correct?
  • Index(es):
    • Date
    • Thread