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: Thu, 1 Dec 2005 17:38:00 -0800
On Dec 1, 2005, at 9:27 AM, David Gimeno Gost wrote:
Actually I've always had both approaches in mind and I've strived
to not make this explicit until now on purpose. This issue is tough
if you want to consider it from a general point of view, and the
level of misunderstanding in this thread already was high enough.
This frankly beggars belief. This far into the thread and we
suddenly find that you haven't even fully described your pattern.
The very fact that you appear to have been unable to clearly
articulate and prove either your problems with the current pattern or
your proposed solution speaks volumes...
On Nov 29, 2005, at 10:05 AM, David Gimeno Gost wrote:
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.
You have not explained how any of these alleged "nasty side effects"
manifest themselves.
(Here, history is relevant, in that in over a decade of using this
pattern I cannot recall any occasion when it has caused any of the
problems you suggest -- see also Greg's response.)
From the consumer perspective, complexity is not affected. A
consumer can use the singleton however they like, and it is robust
against different usage patterns.
"Safety decreases" is a nebulous charge whose meaning is unclear --
if anything, though, safety is increased since the singleton cannot
be prematurely disposed of (it's particularly unclear how you intend
to prevent this...).
Moreover, you have still not, as far as I can tell, clearly and
simply explained what your replacement would be (see below). You
talk vaguely about the possibility of allowing for the dealloc method
to be called, as if this is a silver bullet. It remains unclear how
you intend to ensure that the singleton is deallocated only when it
is guaranteed not to be needed again. Worse than that, your
suggestion is founded on a fallacious argument. dealloc should *not*
be the locus of resource clean-up code...
No valid technical reason has been given to justify that the
singleton's -dealloc method should be prevented from ever being
called.
Because it's not a "technical" reason, it's part of the pattern. The
object is not supposed to be disposed of. Moreover, as others have
noted, it is not guaranteed that dealloc will be called anyway
(during application tear-down). But much more importantly:
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.
*dealloc should _not_ be used as the locus of code for doing general
resource reclamation.* Other current threads have indicated why this
might be the case (see, for example, <
http://lists.apple.com/archives/
Cocoa-dev/2005/Nov/msg02113.html>). In general, however, if you are
managing important system resources you should not leave it to
dealloc to tidy up. dealloc may call another "clean-up" method that
you should be more actively ensuring that you do not make more
demands of the system than are necessary at any particular time.
**** The following is is the important piece: ****
Please describe and show an implementation of the solution you
propose. The current document basically describes two patterns (a
"simple" singleton and a "true" singleton) in about three short
paragraphs and 20 so lines of code. You've written many times this
amount in the thread. It should be trivial, then, to provide a
solution that:
Is easy to understand
Is simple to implement
Allows dealloc to be called
Ensures that dealloc is not called prematurely (to avoid expensive re-
instantiation)
Prevents access of a freed object
Allows clients to abide by Cocoa's memory management rules
Allows the singleton to be accessed from any part of the application,
without assuming an application architecture beyond that supplied by
Cocoa
Does not impose a particular application architecture on the client
(Note: The current pattern meets all of these, with the exception of
"Allows dealloc to be called" -- this is deemed to be irrelevant
since it is argued that you should use a different pattern for
resource clean-up anyway...)
If you can do this, it can then be subjected to proper scrutiny and
the debate can move forward in a useful and constructive fashion.
Until then it's like tilting at ethereal windmills...
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