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: Ken Thomases <email@hidden>
- Date: Sun, 17 Apr 2011 01:00:12 -0500
On Apr 17, 2011, at 12:20 AM, WT wrote:
> On Apr 17, 2011, at 12:31 AM, Kyle Sluder wrote:
>
>>> [[[[self class] alloc] init] autorelease];
>>
>> 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?
What about it? 'self' identifies the actual, dynamic object receiving the message -- in this case, a class. It is not of the static type of the @implementation block it occurs within. Put another way, [self class] is no more dynamic than [self alloc].
>>> + (id) allocWithZone: (NSZone*) zone;
>>> {
>>> dispatch_once(&stAllocWithZoneInvoked,
>>> ^{
>>> NSLog(@"+allocWithZone: block entered");
>>>
>>> stSharedInstance = [super allocWithZone: zone];
>>>
>>> NSLog(@"+allocWithZone: block exited");
>>> });
>>>
>>> return stSharedInstance;
>>
>> 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?
How many stSharedInstance variables are there? How many stAllocWithZoneInvoked dispatch_once predicates are there?
> About these two, once again it all came from Apple's implementation in one of the docs. I read it, it made sense to me at the time, so I used it often. Now, I wanted to replace the use of @synchronized but didn't think of changing anything I didn't absolutely have to change.
Apple's guide for creating singletons has, historically, been much criticized and then subsequently much revised. If you based your implementation on that, you might consider the criticisms as well as the revisions. One critique, as an example: http://boredzo.org/blog/archives/2009-06-17/doing-it-wrong
Regards,
Ken
_______________________________________________
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