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: Sat, 26 Nov 2005 20:57:53 +0100
On 26 Nov 2005, at 16:38, Shawn Erickson wrote:
No Mmalcolm is correct, he is pointing out a flaw in the code you
outline above. Looking at his example...
Yes, I didn't realize it until I saw Uli's mail commenting it. But I
believe it can be easily fixed without affecting anything else I've
said.
On 26 Nov 2005, at 16:56, Shawn Erickson wrote:
In a vast majority of implementations a singleton is implemented to do
lazy allocation and only once in a given process or is allocated once
at some initialization step up front in process initialization. You
can find countless examples of this in Java, C++, etc. coding
examples.
Yes, and I've already acknowledged that. What I'm saying is that there
is no point in enforcing that policy in the sample code provided by
Apple, specially when enforcing it requires overriding a number of
methods that don't need to be overridden if a more general approach is
chosen instead. Interestingly enough, the general approach I'm
proposing not only simplifies the code, but also covers all cases
Apple's sample code addresses and then some.
You want the singleton to exist forever once it's been created? Fine,
just remember you don't own the instance returned by +sharedInstance.
You want the singleton to be deallocated when the application quits?
Fine too, just let the object that controls when the application quits
to assume ownership of the value returned by +sharedInstance. You want
the singleton to be allocated/deallocated as needed? Fine too, just
override -dealloc to set the shared static instance variable to nil as
you suggest below (note that this still allows the singleton to be used
with the other lifetime models, it's just not necessary there).
It is the presumed behavior when talking about singletons in the
general case so that is the perspective Mmalcolm and myself are
talking from.
Yes, and that's my perspective too. What I'm saying is that such
perspective is not part of the pattern and, thus, shouldn't be enforced
unless there is a good reason to do so. In this particular case, it
happens that considering the general case makes things simpler,
requires less code to be written and less methods to be overridden.
Moreover, it allows the lifetime policy of the singleton be determined
by the user of the class instead of by the class itself, thus making
the design even more reusable.
It appears that in this case you want to allow for singleton
deallocation when the singleton is not needed (which is one of many
variations in implementation that you could do, which you do depends
on the intent and paradigm the singleton lives under).
(the following written quickly in Mail.app, so typos possible)
So if you want to allow for singleton deallocation when no one needs
it then...
[...]
...or when you want it to be lazily allocated and live for the life of
the process...
[...]
etc.
Thanks, but that's not what I want. I don't want to tie the design of
my singletons to a specific lifetime model if possible, much less when
doing so complicates things instead of simplifying them.
What motivated me to start this discussion wasn't that I was looking
for sample code to write singletons in Cocoa. I just stumbled upon
Apple's sample code when I was looking for something else and didn't
understand why things were made that way. Trying to enforce a
particularly restrictive lifetime model that requires overriding some
methods for no apparent benefit just doesn't make sense to me.
And I still don't like the idea of being able to call [[alloc] init] on
a singleton, mainly because it requires the writer of the singleton to
take that into account when writing the -init method, and this is very
easy to forget.
On 26 Nov 2005, at 17:12, Shawn Erickson wrote:
If you would like Apple to list alternate implementations in their
documentation about the singleton pattern file a documentation defect.
No, I don't want to see several alternate implementations there. At
first I just wanted to understand why things were the way they were, I
didn't have any particular design in mind. Now that I understand it,
I've come to the conclusion that it's possible to change the current
sample code with something simpler, clearer, more general and more
useful. And that's what I'll submit. Whether the final sample code ends
up being what I propose or something entirely different, I don't care.
But I do want to clear all the issues first and know if there is
something about Cocoa/Objective-C I'm missing that really justifies the
things I don't agree with.
Anyway, thanks for your time. It's been helpful.
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