On Apr 17, 2011, at 13:46, WT wrote: > At the end of the day, the most honest answer I can give is that I wanted to > explore dispatch_once() and thought that doing so in the context of > implementing singletons would be a good learning experience. > > This thread and links to some blogs on the issue have given me much to think > about. I may yet come to change my habit of seeing singletons where they > don't need to be seen, because of this discussion.
I reiterate that it's a singleton if there's only one of them. It's still a singleton if you could create a second one but don't. :) The subtext of a number of the responses in this thread is something important that's not actually about singletons. It's very easy, as a developer, to mislead yourself that something in your implementation is necessary, whereas it turns out to be irrelevant. For example, when I starting writing Cocoa applications, I used to studiously check that the return values from (say) creating collections -- [NSArray array], [NSSet set], etc -- were not nil. It wasn't until something about this came up in an unrelated thread on this list that I learned that checking these particular return values is a waste of time: -- It's not clear that these methods *ever* return nil. -- Probably the only way they can fail is if there's no memory available for allocation, and they may well throw an exception in that case. -- If there's no memory available, your application is likely in such deep trouble that checking the return value is the least of your problems. -- If you do detect a nil return, your application is likely in such deep trouble that there's no recovery path possible. There's no doubt that it's *correct* to check for a nil return after attempting to create any new object, but in some cases it's a complete waste of time and keystrokes. "Then don't do that." _______________________________________________ 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
