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: Fri, 2 Dec 2005 15:06:04 +1100
>
Well, you certainly *tried* to do so, but what I came away with from
>
the discussion was "one more C++ guy trying to solve non-existent
>
problems".
I think David is getting the rough end of the stick here.
What I read was "one more person complaining about what appeared to be
poorly-explained complexity in Apple sample code".
The fact that the "I've been doing this for ten years" crowd howled him down
did not undercut the complaint, in my opinion. Who cares that experienced
programmers have never had a problem with it? What about the rest of us?
I hope we're all talking about the same sample, the one at
http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaObjects/Artic
les/CreateSingleton.html which contains:
- (unsigned)retainCount
{
return UINT_MAX; //denotes an object that cannot be released
}
Why "UINT_MAX" and not 1 or 2 or 10 ? Is there really something in the box
that looks at UINT_MAX ? This is voodoo. Is there more voodoo in the box
that makes it *mandatory* for a singleton to do the
retain/release/autorelease hack? Who can tell?
David asserts that the hackery is not *mandatory* - no-one else has
contradicted him authoratively, and they can't unless they expose
information about the internal voodoo, and if they know that stuff, then
***it should be explained in the sample***
Once you start heading down the "lets make sure people don't screw up when
they call the wrong methods on this code", you start trying to build a
world-class-idiot-proof solution and frankly, the idiots will always get
dumber as your code gets smarter.
If someone releases a singleton when they shouldn't, why not let them crash
and burn? They clearly don't know what they are doing so they've probably
got other retain/release problems as well.
Imagine the developer who does
d = [NSDocumentController sharedController];
...
[d dealloc];
because he doesn't understand the difference between dealloc and release.
Isn't it important to catch this case as well? The sample doesn't.
Is it guaranteed that overriding retain/release/retainCount/autorelease is
sufficient for all future changes that Apple might make to the memory
management scheme? Those of us who don't work on the inside can't say for
sure...
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"? Lets check the documentation:
http://developer.apple.com/documentation/Cocoa/Reference/Foundation/ObjC_cla
ssic/Protocols/NSCopying.html#//apple_ref/occ/intfm/NSCopying/copyWithZone:
"Returns a new instance that's a copy of the receiver."
Once again, this seems to me like something that you should be protecting
against, not silently sweeping under the rug. I'm not saying I could have
done better, far from it. But this is a method thats just plain missing
*from the sample*, presumably because the sample "knows" the voodoo NSObject
uses to implement copyWithZone: Or not? I have no idea.
The "non-existant problems" argument doesn't wash - Apple deliberately put
all that no-opping in for a reason - they foresaw problems and attacked them
in advance, with no indication as to how to determine completeness of the
fix.
It seems to me that if the 'nopping out the
retain/release/retainCount/autorelease' stuff is sufficient, then Apple
could have added a base class NSImmortal which did that stuff for you, and
left you to implement whatever 'new/alloc/etc' hackery you want to do
actually allocate and store your shared instance. Then they can show what
needs to be done for NSSingleton seperately from NSImmortal.
Now, I agree that when David said:
>
To make it clear that Apple's singleton sample code is broken, that
>
there is no trade-off that justifies a singleton to be written that
>
way.
that he was expressing a fairly extreme opinion - "broken" is not the word
I'd use, unless you consider it from the perspective of "providing
educational value, explaining what you MUST do to write a singleton" rather
than "functioning correctly(?) even if you mistreat it".
The trade off that justifies that approach is, sadly, that Apple have a
finite number of hours to develop documentation and must spend their
resources where they get the most bang for buck. Pretty much everyone on
this thread understands the topic enough such that there's no point, from
our personal perspectives, on improving that specific sample. Its only a
question of how much you care about the novices who follow ....
_______________________________________________
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