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: Shaun Wexler <email@hidden>
- Date: Thu, 1 Dec 2005 20:15:34 -0800
On Dec 1, 2005, at 8:06 PM, Jeff Laing wrote:
If you look at Shaun Wexlers recently posted (and the updated)
MortalSingleton, specifically:
- (id)copy
{
return [self retain];
}
why on earth would it be "good form" to allow the caller to even
think he
can *copy* a singleton? Or does the contract for -copy say "might
not give
you a copy"?
This is no different than making a "copy" of an immutable object such
as a NSData or NSString... most classes will simply retain the
object, which isn't allowed to change or move.
Here is a very good example of where a mortal singleton is the best
choice: DSP. For instance, to perform FFT, you need to create a
complex array of "twiddle factors" which are the cos/sin
coefficients, and it's a large object and expensive to create, so as
long as any DSP objects are using the shared fft_setup :
MortalSingleton object, great, but as soon as none of them need it,
it gets deallocated. The same goes for smaller objects like NSColor,
etc. Raw colors might be kept in a lookup table of packed 32-bit
uint, where it's efficient for them to be singletons when asked for a
NSColor representation.
Overall, a mortal singleton tends to be more useful than an immortal
one (which should be used for an object whose premature and/or
accidental deletion would be catastrophic to the app).
--
Shaun Wexler
MacFOH
http://www.macfoh.com
"Intellectuals solve problems, geniuses prevent them." - Albert Einstein
_______________________________________________
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