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: David Gimeno Gost <email@hidden>
- Date: Tue, 29 Nov 2005 19:05:59 +0100
On 29 Nov 2005, at 03:06, Andy Lee wrote:
I've lost track of who favors what, but FWIW, I'm for...
We are in full agreement, then.
If you take a look at the post that originated this thread, all I was
asking was precisely why things weren't done the way you and others
have suggested? Why was +allocWithZone: overridden? Why were the
retain/release methods overridden? And in the mails that followed I
added the question why was the -dealloc method prevented from ever
being called?
In all this time, I've only been given valid technical reasons for
overriding +allocWithZone:, namely that we may want to be able to
create a singleton instance as we would for any other object. Do I
believe this is really necessary? No, but I don't really know for sure.
Maybe we want to be able to put the singleton instance in a nib, or
something like that. So this is a valid technical reason and it should
at least be considered.
The problem is that overriding +allocWithZone: the way it is done in
Apple's sample code breaks the object ownership contract in client
code, thus requiring all those retain/release methods to be overridden
just to ensure that the singleton runs fine regardless of whether
client code follows memory management rules or not. But by doing that
we are creating a lot of nasty side effects: complexity increases,
safety decreases, bugs may be introduced, buggy client can go by
unnoticed, applicability of the pattern decreases and, worst of all,
-dealloc is prevented from ever being called.
So I said to myself that there should be a better way to accomplish our
objective without all that unnecessary overhead. Since the root of the
problem was breakage of contract in +allocWithZone: the solution should
aim to restore the contract. So I suggested an alternate implementation
of that method. But my first attempt had a bug and failed. The bug was
easy to fix, however, and I demonstrated that it was indeed possible to
get that functionality without the need to add any unnecessary
constraints or nasty side effects. I wasn't really suggesting it as an
alternate implementation, I was just trying to demonstrate the concept.
Then, Uli Kusterer provided a much better implementation using a
different approach: instead of overriding +allocWithZone: he chose to
override the -init method to ensure that only the instance created by
the +sharedInstance method is ever returned. What I like most about
this approach is not that the code is more self-documenting, but that
it completely eliminates another nasty side effect that I haven't
mentioned in the above paragraphs and that any +allocWithZone:-based
approach would have: the repeated -init call problem.
For reasons that escape me, knowledgeable people in this list has kept
arguing with me that I shouldn't really be concerned at all with the
nasty side effects of the current Apple's sample code implementation.
No valid technical reason has been given to justify that the
singleton's -dealloc method should be prevented from ever being called.
Yet some people have gone as far as saying that the functionality that
everyone would put there for any other object, should be put somewhere
else for singletons, just because -dealloc has been prevented from ever
being called for no apparent reason.
So here we are. I no longer think there is a point in trying to change
Apple's sample code, but at least everyone interested in the issue can
refer to this thread and make their own conclusions.
Regards.
_______________________________________________
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