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: Thu, 1 Dec 2005 22:58:01 -0800
On Dec 1, 2005, at 9:47 PM, David Gimeno Gost wrote:
Well, I thought I had stated clearly that Uli Kusterer had already
done it, so I considered it more appropriate to refer to his
implementation rather than proposing it as if it was mine, but here
it is if that's the problem (minor changes made and comments added,
let me know if there is something wrong about making the changes):
You've variously stated that you didn't have an implementation,
provided part of an implementation, and championed others' buggy
implementations... It's not clear why this:
@implementation MySingleton
+ (MySingleton*) sharedInstance
{
static MySingleton* sSharedInstance = nil;
@synchronized( self ) {
if ( sSharedInstance == nil ) {
// Note: calls -singletonInit instead of -init
sSharedInstance = [[MySingleton alloc] singletonInit];
}
}
return sSharedInstance;
}
- (id) init
{
[self release];
self = [MySingleton sharedInstance];
return [self retain];
}
- (id) singletonInit
{
self = [super init];
if ( self != nil ) {
}
return self;
}
@end
would be a solution, since dealloc is never called.
Uli's example allows premature deallocation, and (certainly the
implementation here <
http://www.cocoabuilder.com/archive/message/
cocoa/2005/11/26/151142>) does not appear to be thread safe.
You have not explained how any of these alleged "nasty side
effects" manifest themselves.
Whenever you expect -dealloc to be be invoked.
You shouldn't expect it to be. It's part of the pattern that the
object is not deallocated. You should use the appropriate Cocoa idiom.
Whenever you override -init following the convention shown in "The
Objective-C Programming Language" (i.e. not taking into account the
fact that it could be called more than once for the same object).
That's a fair point, and now called out in the documentation.
Whenever you copy/paste buggy code that uses the singleton as any
other object and reuse it for use with an object that's not a
singleton.
How this manifests itself is unclear.
It remains unclear how you intend to ensure that the singleton is
deallocated only when it is guaranteed not to be needed again.
It is automatically ensured by just requiring client code to follow
the memory management rules.
Given that the in implementation you propose above dealloc is not
called, the solution remains unclear.
*dealloc should _not_ be used as the locus of code for doing
general resource reclamation.* Other current threads have
indicated why this might be the case (see, for example, <http://
lists.apple.com/archives/Cocoa-dev/2005/Nov/msg02113.html>).
Actually, I already had this in mind and considered it a reason to
use -dealloc for resource deallocation until garbage collection
becomes available. Let me elaborate:
We cannot think of -finalize as a -doCleanUp method, because what
really makes it special is that it will be _automagically_ called
when the garbage collector determines that no other object keeps a
reference to the instance. The closest we can get to this behavior
without GC is to rely on -dealloc being called when all retained
references to the object are released. This would make it easier to
modify the code to take advantage of garbage collection when it
becomes available, wouldn't it?
This is wrong. (I can't elaborate.)
Let me know if you believe the above implementation fails to
satisfy any of those requirements.
dealloc is not invoked.
I don't see it as being any easier to understand than the current
implementation -- in particular:
- (id) init
{
[self release];
this is certainly not going to make it easier for a novice...
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