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 protected])
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
