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: Marco Scheurer <email@hidden>
- Date: Tue, 29 Nov 2005 15:49:16 +0100
On Nov 29, 2005, at 3:15 PM, Ondra Cada wrote:
Serge,
On 29.11.2005, at 13:11, Serge Cohen wrote:
** 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).
... for THEIR singletons.
Our ones is *some* cases might need to be used through alloc/init.
E.g. to co-operate properly with client code without our reach,
which was written for using normal instances, but in the conditions
*we* need it to use a singleton instead.
Could you give us a meaningful example? Otherwise this is just idle,
obfuscating, speculation.
(<rant> Alas too many programmers--including you, it seems--keeps
forgetting in practice we very often have to use code whose sources
are unuavailable, and thus we have to cope with them the best way
we can. </rant>)
This seems completely irrelevant. What are you talking about?
We are talking about singleton code that YOU WRITE, and that you or
others may use. Why anyone would choose to implement a singleton by
tweaking alloc is beyond me. What exactly is the problem of alloc?
Could it be the massive waste of time and space to allocate the
required memory?
In fact, your doing everybody a big disservice if suddenly alloc does
not alloc anymore, even for a lowly singleton class. You are breaking
a convention so that if your class client decides to break another
convention it would "work". This is crazy.
Even doing it by tweaking init seems bad compared to a
+sharedInstance method.
If your code clients choose to ignore conventions, common sense, and
your documentation, and decide to alloc-init a new instance of your
singleton, then so be it. It is not your responsibility to enforce
that rule.
Just like it is not NSObject's job to make sure that it stays purely
abstract and never instantiated, just like it is not NSWindow's or
NSImage's job to make sure that they are not initialized with init
but with a proper initWith... message, and so on.
Keep it simple.
Marco Scheurer
Sen:te, Lausanne, Switzerland http://www.sente.ch
_______________________________________________
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