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 16:59:53 +1100
> > 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.
>
> myColor = [[NSColor whiteColor] retain];
Hmmm, I had not considered that that would be returning a singleton at all.
I can't see anything in the NSColor docs that suggest it, but then again, I
also can't see any methods that actually allow you to modify the content of
an NSColor either so I guess its safe to pass the originals around. But
since they haven't told me its a singleton, I must retain it to be safe.
But my original question was really aimed at singletons like the
NSDocumentController where Apple clearly state that:
------8<--------snip------8<----
init
This method is the designated initializer for the NSDocumentController.
- (id)init
Discussion
The first instance of NSDocumentController or any of its subclasses that is
created becomes the shared instance.
------8<--------snip------8<----
They certainly are not saying "you must only create one of these via
+sharedDocumentController. It is interesting to note that it is
+sharedDocumentController (and not -init) that provides the explanation:
"If one doesn't exist yet, it is created. Initialization reads in the
document types from the CFBundleDocumentTypes property list (in Info.plist),
registers the instance for NSWorkspaceWillPowerOffNotifications, and turns
on the flag indicating that document user interfaces should be visible. You
should always obtain your application's NSDocumentController using this
method."
Is there a reason why I should explicitly retain the shared
NSDocumentController in a regular application, rather than just re-retrieve
it everytime I need it?
_______________________________________________
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