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: Serge Cohen <email@hidden>
- Date: Tue, 29 Nov 2005 13:11:22 +0100
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 29 nov. 05 à 10:17, Ondra Cada a écrit :
David,
No you don't. Correct client would first alloc/init the singleton,
then release it. Unless someone other did the same, and unless we
did some trick singleton-level (be it reimplementation of retain/
release/dealloc or overretaining or whatever), the singleton goes
poof. That's *not* what we wanted: we want it to survive infinitely
(or at the very least till app is about to quit).
Well indeed all the singleton class from the Cocoa framework I ever
used are supposed to be accessed through the +shared... method. It is
clearly stated in the documentation (ie. http://developer.apple.com/
documentation/Cocoa/Reference/ApplicationKit/ObjC_classic/Classes/
NSApplication_index.html first paragraph of the class description)
So the implicit rule is that a singleton class is NOT alloc/init by
it's user, but accessed through a class method with a name starting
by shared...
Some user night not properly read documentation (or doc. might be
unclear) and not explain that a class is meant to be singleton, in
which case some one will wrongly use alloc/init ... in this case
you're helping the user by triggering an exception or something
equivalent to let the developer realise he made a mistake, but please
don't break-down/replace the meaning of the these methods.
(The most obvious example is a forgotten (auto)release: that is a
violation of the memory management rules all right, but the
application runs without a glitch; it leaks memory a bit, but
unless the object in question is big or tooo many of them and/or
the app runs for a long long time, nobody ever notices.)
Indeed this is not nice at all, neither is a 'one too many' auto-
release which hardly gets discovered : this is a feature which make
the all coding an harder process because cause is far (in time) with
its consequence. I'd love to see a way to ''enforce' the policy of
auto-release .
Back to business: making the class to adhere to memory management
rules means exactly this:
** if the client follows the rules, the class does exactly what we
want it to do **
The client here should follow the rule of knowingly use a singleton
class, hence don't call the alloc/init, but use tha class shared...
method (this is the implicit rule set by the Cocoa framework API).
There is nothing wrong about _using_ object deallocation to do
the app-quit cleanup.
There's all wrong with it. I did it, long ago. I've learnt the hard
way.
Can you be more precise on this one? (avoiding us to learn the hard
way).
Serge.
PS: I just realised I'd much better have let the thread die ... re-
reading this message I have the feeling it only repeat what was
already there... except the last question ... what's wrong with using
dealloc for cleanup of singleton???
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFDjEUU5EPeG5y7WPsRAg/gAKCReeXAjSfp6r1j4xmdTSpOZ14f5gCeLux2
RQFipEz/scynFIK724q+bXg=
=O/ue
-----END PGP SIGNATURE-----
_______________________________________________
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