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 15:42:49 -0300
Hi Ken,
On Apr 17, 2011, at 3:00 AM, Ken Thomases wrote:
> 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].
Tell that to Erik Buck and Donald Yacktman, the authors of 'Cocoa Design Patterns'. They explicitly assert on the second paragraph of page 151 that [self class] is used instead of self to support instantiating the appropriate subclass. Clearly there is some confusion regarding this matter, even among people more experienced than I, so I don't feel so bad by being confused about it too. :)
> + (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?
Yes, of course. What threw me off was that Kyle's comment made it look like it was the implementation of +allocWithZone: itself that broke the ability to subclass and not the fact that I'm using a static variable that would be the same for all subclasses.
> 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
That is a very useful and interesting reference. Thank you for pointing me to it. I don't agree with every point the author makes, however. In particular, I agree with one of the commenters, who argues that overriding the memory management methods is a good thing. But that's again going into a philosophical discussion and I'd rater not go there here.
Thanks again for your help.
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