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:23:56 -0800
On Nov 26, 2005, at 3:14 PM, David Gimeno Gost wrote:
[[[self alloc] init] release]
in any of my programs. This code effectively does nothing, and its
side effects do everything. Yes, the comment elaborates on that,
but in this case I'd prefer self-documenting code.
Actually, the problem with that code is not that it's not self-
documenting, but that the two methods that are involved depend too
much on each other. The ugly code is just a consequence of this
(the +sharedInstance method shouldn't have to undo what
+allocWitZone: did).
This strong coupling could be greatly reduced by the introduction
of another static variable to flag whether +allocWithZone: does
indeed need to increase the retain count.
It's not clear how this is a simpler, more efficient, and more
elegant solution than the original?
But these are implementation details and I'm currently more
interested in proving that the lifetime constraints should be
removed from the design of the class
Again, the point is that the singleton pattern was designed in part
precisely because it does impose a lifetime requirement. A singleton
is frequently a resource-hungry object that takes some time to
instantiate. Consider the font manager, for example. It must search
several locations on the filesystem to collect the information it
needs. Suppose, then, that it obeyed the normal life-cycle. Then
you implement a simple view that uses the font manager to draw some
text:
- (void)drawRect:(NSRect)rect
{
MyFontManager *fm = [[MyFontManager alloc] init];
// use fm to draw text...
[fm release];
}
A new instance is created each time the drawing routing is invoked.
This will be horribly inefficient.
The current pattern has been used (as far as I can tell) without
issue for almost two decades now, and it's still not clear to me what
the problem is?
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