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: Kyle Sluder <email@hidden>
- Date: Sun, 17 Apr 2011 08:03:05 -0700
On Apr 16, 2011, at 10:20 PM, WT <email@hidden> wrote:
>
> On Apr 17, 2011, at 12:31 AM, Kyle Sluder wrote:
>
>> Do you really need a singleton, or just a default instance?
>
> A singleton.
Okay, next question: why? Is there a reason that you can't replace all your calls to +alloc/-init with +sharedInstance?
>
>>
>> All of these could be made static variables within the method body,
>> increasing readability and reducing pollution of the global scope
>> without affecting storage longevity.
>
> It's the coding style I'm used to, listing the statically allocated variables at the top. I don't see how declaring them inside the methods that use them helps to reduce pollution of the global scope, since they have to be visible to different methods in the same compilation unit anyway.
Because variables are scoped to their enclosing block. Top-level variables are global scoped. Variables within blocks are accessible only within that function's scope.
If you find you only use a global static variable from within one function, you lose nothing by moving that static variable into the function. Well, except for the ability to access it from other functions, but you weren't using that.
>
>>
>> Rather than relying on -allocWithZone: to return the shared instance,
>> why not assign to stSharedInstance here?
>
> No reason other than that this implementation is based on the singleton implementation I saw in some Apple documentation.
Mike Ash had a good blog post about singletons which you may want to read: http://www.mikeash.com/pyblog/friday-qa-2009-10-02-care-and-feeding-of-singletons.html
>
>>
>> You are in a class method. self == [self class], so no need to call +class here.
>
> What if I'm trying to subclass this singleton?
Hint: +class is defined to return self.
>
>>
>> Of course this means you can't subclass this class.
>
> Why not? As long as the subclass doesn't override +allocWithZone:, this shouldn't be a problem, no?
See Dave's reply.
>
>
> but the compiler complained that self is read-only within the scope of the block. I needed a way to write to self and I couldn't redeclare self, hence a writable tempSelf.
Bah. I swear one of these days I'll remember the const copy thing that happens to non-__block variables. :) My use of blocks almost never touches self, so the relatively few self gymnastics I see or use are about avoiding leaks.
>
>
>
> Well, it is if I need a true singleton and sometimes I do. In fact, I kinda often do. I tend to break down my code into classes with very well defined, and typically few, responsibilities. Often times, making them singletons simplifies my code.
Making them singletons can never be simpler than just not creating more than one instance of a regular class.
>
> For instance, I never put all the core data stack methods in the application delegate. I have a singleton that takes care of all things core data (well, all things that can be done generically). Likewise, I have a singleton for locale "utilities". All my number and date formatters are there, in one place, created once on demand and accessible everywhere else through the singleton. That's the kind of usage I have for singletons.
As for the first example, do you bother to make your app delegate a singleton? Probably not. So why worry about the Core Data stack?
As for the second, most "utility" methods can be written as categories and/or class methods or functions.
>
> Granted, sometimes they don't *have* to be singletons (they don't represent expensive resources) and I could just as well have a default instance. The locale utilities is such an example. Then, again, why allow for that possibility when it's logically sound that I should only ever need one instance?
Because code that never gets used is code that should never be written.
>
> Rather than go into a philosophical discussion of the kind "when/why singletons?", let me rephrase and focus my original plea for help: how would you implement a *true* singleton class that supports subclassing?
This is s contradiction in terms. Because every subclass instance is also an instance of its superclass, there will be multiple superclass instances.
--Kyle Sluder
>
_______________________________________________
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