Closed MSch closed 13 years ago
Singletons are more often used as they should, I am guilty too - we definitely need such a macro.
I hate the macro. As I said it's trying to be Ruby when it's ObjC.
Practical Q: Why don't you just add an accessor to AppDelegate? That way you only ever have one singleton which is provided by Cocoa and don't need your own sharedWhatever
?
Funny thing, that macro is one of the most used things in the ObjC world. I already modernized it (with gcd) and with ARC it's going to be A LOT smaller. For some managers/bla it's pretty handy to just singleton it. And yes, adding it to the AppDelegate would be a solution in many cases - but that feels like polluting the appdelegate and putting things in there that don't really belong - a matter of code style.
I agree, Singletons are generally used too often just out of convenience, but there are situations where singletons are the right choice. Adding everything to the AppDelegate is imho even worse than creating too many singletons - but is also not possible for a library that offers helpers.
Ok, closing this now, if someone has anything to add, just reopen
See https://github.com/foundationkit/FoundationKit/commit/93ef4b664e0135c249cfe6091aa8233b479b2574#commitcomment-469424
I'm against adding a singleton helper macro (especially since it doesn't compile with ARC ;)) but even the shortened, ARC-ready version is IMO unnecessary.
Singletons are only used sparingly and for those 1 (2?) times where you do need them writing a five line statement is IMO preferably.
The other argument against the macro is if Xcode can deal with it and autocomplete/infer the type of
shared<<ClassName>>
when accessing the singleton?