Re: Proper way to create a singleton without @synchronized ?
Re: Proper way to create a singleton without @synchronized ?
- Subject: Re: Proper way to create a singleton without @synchronized ?
- From: WT <email@hidden>
- Date: Sun, 17 Apr 2011 17:46:44 -0300
Hi Quincey, thanks for pitching in.
On Apr 17, 2011, at 4:58 PM, Quincey Morris wrote:
> 1. Conceptually, I think Joanna is right. In practice, I've found that using the class as a singleton doesn't always serve the purpose -- though I can never remember the usage case that's a problem. I think it's something like trying to use a class object as a 'didEnd' selector delegate, where you end up wanting encapsulated instance variables.
I won't insist that my use of singletons is always justified. I'll merely say it doesn't hurt to use them in the way that I most often use them, namely, as providers of specific services (locale utils, reachability, core data, and so on). At least that's my experience so far.
> OTOH, I'm not sure I understand your objection as expressed above. You can of course subclass a class (i.e. override class methods). Having to search for the class name seems no different from the case where you change the name of your singleton-getter-method. But let's not get side-tracked into that ...
My objection comes in the context of already having a code base in place that uses a class object. If a need to subclassing that class arises, then the code base may need a significant amount of change. Writing the code base to begin with using a singleton approach reduces this problem.
> 2. FWIW, I'm generally with Kyle and others who are suggesting that trying to implement forced, generalized singleton-ness may be a practical un-necessity.
Fair enough, but I do find clutter in classes to be distracting to the point of making it difficult to understand what the classes' responsibilities are. I've worked on projects where other people have made the app delegate responsible for everything and the kitchen sink. It's one thing to have a few core data stack methods in the app delegate; it's another to do a lot of one's core data tasks in the app delegate. Personally, I prefer to move all of that to a class whose sole responsibility is to manage core data tasks.
> A while back, I asked on this list whether a singleton is an object that there *is* only one of, or it's an object that there *can be* only one of. The answer, from someone whose opinion I respect (and who is almost always right) was "is", not "can be".
>
> So the issue being discussed in this thread is not how to create a singleton, but how to prevent the creation of a second object of the class, which is a different matter.
To be fair, the issue was originally "is there something else in this code that I'm missing". The thread has since turned into why/when it is appropriate, or not, to use a singleton.
> I understand that you're implementing forced, generalized singleton-ness as a matter of interest as much as anything else, and I'm not saying don't do it, but I am asking how it protects you ... from who? what? ... more effectively than the low-tech solution outlined above.
The honest answer is that I don't know (how it protects me, from who (or whom?) or what), but I won't find out if I don't explore the issue, will I? :)
> 3. This thread really isn't about singletons at all. Looking back at your original post, it's really about thread-safe creation of shared objects:
That's certainly a big component of my original question, yes, but I also had an interest in seeing that question answered in the specific context of implementing a singleton.
> On Apr 16, 2011, at 20:04, WT wrote:
>
>> Among other things, I wanted to replace my usage of @synchronized singletons, and dispatch_once() seemed the perfect mechanism for that.
>
>
> In that context, my question is: what's wrong with @synchronized? After all, it can't be a performance issue when it only happens once per singleton class. Why is @synchronized an imperfect mechanism?
It probably isn't an imperfect mechanism and is probably fine from a performance point of view. And, yes, attempting to replace that mechanism with dispatch_once() may be a case of premature optimization. I won't deny any of that.
At the end of the day, the most honest answer I can give is that I wanted to explore dispatch_once() and thought that doing so in the context of implementing singletons would be a good learning experience.
This thread and links to some blogs on the issue have given me much to think about. I may yet come to change my habit of seeing singletons where they don't need to be seen, because of this discussion.
WT
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden