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: mmalcolm crawford <email@hidden>
- Date: Sat, 26 Nov 2005 16:44:26 -0800
On Nov 26, 2005, at 4:20 PM, David Gimeno Gost wrote:
You have completely missed my point.
Yes, and I suspect I continue to. It's becoming increasingly unclear
exactly what the problem is -- the point seems to change with every
post...
On the contrary, what I'm saying is precisely that the design of
singletons in general, including those written _using_ Cocoa (but
not those _provided by_ Cocoa), shouldn't enforce a particular
variation of the pattern and that not enforcing such arbitrary
constraints makes it possible to design singletons that can support
any particular lifetime model, while at the same time being better
from any coding point of view (i.e. easier to write, easier to
understand, easier to use, safer, more reusable, etc.).
I don't see what's difficult to understand about the current model,
how it is difficult to understand or use, or how it is unsafe? The
pattern as described is trivial to implement, and even easier to use
(this thread has probably already taken more time and effort than the
average developer will expend in a decade creating singletons...) --
especially in an environment in which there may be different usage
patterns.
(Consider, for example, that if you allow "mortal" singletons, the
implementation of +sharedInstance should be:
+(id) sharedInstance
{
@synchronized(self)
{
// the implementation here is largely irrelevant
static mySharedInstance = nil;
if( mySharedInstance == nil )
mySharedInstance = [[MySingleton alloc] init];
}
// this is the important part
return [[mySharedInstance retain] autorelease];
}
Consider also that you already overlooked an important bug in your
first implementation. It's not clear now what your preferred
implementation would be?
)
mmalc
_______________________________________________
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