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: Mon, 28 Nov 2005 21:38:34 +0100
On 28 Nov 2005, at 20:29, glenn andreas wrote:
Objective-C does not have "Destructors".
Exactly. It's bad enough that Objective-C does not provide such
facilities. Lets at least adhere to the conventions of the memory
management provided by the framework, whether singleton or not. Doing
that does not prevent the singleton from being a singleton.
Cocoa _does_ provide a mechanism to provide cleanup when the
application terminates - registering for NSApplicationWillTerminate
notification. It not only works well in theory, but works well in
practice as well.
I've already stated that such approach either breaks encapsulation or
requires additional methods to be defined in my singletons. Those
methods would be semantically identical to -dealloc, but cannot be
named -dealloc for the sole reason that I have added an arbitrary
constraint to my singletons whose only purpose is preventing -dealloc
from ever being called. This is crazy.
BTW, someone else has already provided a real-world example that
contradicts what you are saying.
There's no need to "fight against the stream" to try to make Cocoa
work like C++ - just use the provided idiom and conventions...
I'm not trying to make Cocoa work like C++. What I'm saying is
precisely that there is no technical reason to not let singletons
follow the same Cocoa memory management rules as any other object.
Cocoa's memory management is good enough to properly handle singletons
without the need to add any arbitrary constraints to them.
Why should singletons have a special-purpose resource deallocation
method that cannot be named -dealloc, while every other object would do
that in -dealloc? What if I later decide that the singleton shouldn't
really be a singleton at all?
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