On Apr 17, 2011, at 12:04, WT wrote: > On Apr 17, 2011, at 3:52 PM, Joanna Carter wrote: > >>
>> Tell me; maybe it's my background in other languages, but I would tend to >> use a "static class" as a singleton; or, at least, design a class with only >> class methods/properties, with static "fields" declared in the >> @implementation section of a class. >> >> Why this fascination with going to all the trouble of creating a singleton >> rather than using the "static class" approach? > not a fascination, but simply a preference and being used to coding that way. > As for the "static class" idea, what happens if you need/want to subclass > that class? Then you have to search for and change all the places in your > code base that refer to it. 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. 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 ... 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. 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. "Doctor, doctor, it hurts when I do that." "Then don't do that." It's not bad advice here. The question is who you're trying to prevent from doing what. If you declare (publicly) neither a factory method nor an initializer, leaving your "sharedXxx" class method as the only way to obtain an instance of the class, then no one's going to create another object without a determined effort to contravene your API (unless I'm overlooking something obvious). 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. 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: 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? That's a genuine question, not a snark. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
