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: Ondra Cada <email@hidden>
- Date: Mon, 28 Nov 2005 22:20:02 +0100
Oh sigh...
On 28.11.2005, at 21:38, David Gimeno Gost wrote:
Objective-C does not have "Destructors".
Exactly. It's bad enough that Objective-C does not provide such
facilities.
Bad enough? Man, that is one of the *most profound* advantages of
ObjC if compared with the majority of other languages.
It is plain wrong to do what C++ does, namely to mess up a langauge
by things which are much better to be implemented library-side. If
for no other reason, then since a programmer can very easily patch up
libraries (using techniques like categories, posing, and so forth),
but one can't reasonably change the code generator.
Lets at least adhere to the conventions of the memory management
provided by the framework, whether singleton or not.
More or less all others are trying to point out to you that's exactly
what the overriding of memory management methods achieves.
Doing that does not prevent the singleton from being a singleton.
Agreed this time.
A singleton is just a name, a pretty generic one. There is *a number*
of *proper* implementations of something which can be named a
singleton. The best one -- since simplest and thus by far most
foolproof -- would be the one somebody (IIRC, Uli) has brought to
notion yesterday or so:
+sharedInstance { static id myself=nil; if (!myself) myself=[[self
alloc] init]; return myself; }
That's a very valid *singleton* we just made here. It does not quite
adhere to the memory-management conventions though, or rather, it
does, alas breaking so the contract of being a singleton :)
Now, in some specific cases that may be a reason to adhere to them
*whilst* keeping the singleton contract. That means reimplementing
allocWithZone:, or init, or both, and also dealloc/retain/release.
Sometimes (actually pretty often--in my 15-year experience with Cocoa/
ObjC (of course, has not been called Cocoa thence :)--much more often
than not) it's best for a singleton never to be destroyed at all:
there's simply no need. Sometimes it might be removed and re-created
on demand. *Depends on the particular class*.
Anyway, to use the *object deallocation* tool -- the dealloc method
-- for the *application quit clean-up* -- is plain wrong. You are
just using a completely inappropriate tool; it would be something
like using an exception instead of an NSError for reporting an
unsuccessful operation...
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
No, they would not. Not the slightest bit. See above.
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.
Nope. Crazy is not to grok that app-quit cleanup is a very very
different beast from object deallocation.
Unlike C++ and similar junk, Cocoa does this right, giving us two
completely unrelated mechanisms, each of them to be used where it
belongs to: dealloc for the case the object being deallocated, i.e.,
to clean-up in the context of the process it lives in. And
NSApplicationWillTerminate notification for the case the process
itself is about to die, i.e., to clean-up in the context of the
operating system environment.
Rarely enough it happens so that these two needs are fulfilled by the
same operations -- heck, in practice it is as near to never as making
no difference.
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?
That's completely irrelevant. The above does apply to "normal"
objects and singletons as well. Both of them may use dealloc or may
not, depending on your design (normal objects would very rarely not
to, but even they could, in some cases when you wanna cache them
rather than dealloc and then re-create). *Completely independent on
this*, both of them may use the app-quit (or any other) notification
or not. It's as simple as that.
---
Ondra Čada
OCSoftware: email@hidden http://www.ocs.cz
private email@hidden http://www.ocs.cz/oc
_______________________________________________
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