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: jkp <email@hidden>
- Date: Mon, 28 Nov 2005 09:23:28 +0000
Hey all.
I've also been passively following this thread, and whilst at first I
thought David was being a bit pedantic, I actually think he raises a
very valid point. Yesterday I was working on some code with a
singleton class that had all the extra measures being debated in this
thread (overriding retain / release etc) and they were actually
causing far far more problems than then solved. Specifically when it
came to ending the process - there was a method called on the
singleton super-class called +destroyAllSingletons - this was being
called but everything was ending up as a mess because the retain
release calls did not behave in the expected manner (nested
singletons were specifically a problem). In the end it was far
easier (and cleaner) to remove the overridden methods and make it
clear to the users of the class that the correct memory management
rules still applied - ie, dont release what you dont own.
In our case the extra retain needed to keep the singleton in play is
obtained by having a static CFDictionary in the AbstractSingleton
class itself that holds each singleton instance. Therefore, as soon
as you refer to a singleton, it is added to this dict and you never
have to worry about it again. If you really wanted to destroy a
singleton before the end of the app, all you would have to do is
write a method to remove it from the dict, accessing it using the
Class as the key.
I do think that this thread has raised some interesting points, and
on balance, I think David is right in his assessment. There is
nothing about a singleton that says it should have the same lifetime
as the process it runs in, so why should we protect against bad
memory management, and limit ourselves in this way?
Just a couple of thoughts anyway.
Jamie
On 28 Nov 2005, at 08:54, Uli Kusterer wrote:
Listening to this thread going on and on, I can't help but think
there's over-engineering going on. The OP was simply wondering
whether there was a reason for Apple's singleton sample code being
so complicated, and it looks like we've found it's not really in
any way necessary to have this code for the typical singleton (i.e.
like +sharedWorkspace).
The case where this singleton code seems not un-sensible is for
constant stuff, such as [NSNumber numberWithInt:1], though even
there I'd personally consider it a matter of taste whether you'd
want to go to such lengths.
I can see how one would warn or prohibit certain memory management
practices on a singleton to catch usage bugs (like deallocation
through unbalanced -release calls, which is easily detected for an
object that's supposed to live as long as the app). This is
especially important when you have lots of projects, or co-workers
who may not be familiar with the code you wrote.
Apart from those considerations, I really think the reduction of
lines of code (as Wil Shipley would put it: "a deleted line of code
is a debugged line of code") is much more important than trying to
come up with a complex safety net of code that only introduces new
bugs. Just look at the code samples posted and all the bugs people
pointed out in them.
So, different from other Apple recommendations, I'd suggest to
every newbie to just ignore this one. Write the simplest singleton
code: A class-level accessor that lazily instantiates a regular
object into a static variable. Maybe override -dealloc to NSLog() a
warning. Leave the more complicated stuff until you're actually
tracking down an insiduous bug that seems to be related to the
singleton or once you've profiled using Shark and know for sure
that a particular singleton is a bottleneck and needs to be optimised.
Just my $0.02.
Cheers,
-- M. Uli Kusterer
http://www.zathras.de
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40kirkconsulting.co.uk
This email sent to email@hidden
_______________________________________________
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