The ridiculous amount of effort that we have to go through to define private properties (just sheer amount of text around them) makes me miss the pre-property days... I still define iVars the old fashioned way. The whole language would do well to have some syntax sugar added akin to Java's private, public, protected for properties so we could just go @private NSString dog; @public NSString cat; ... Oh Wait! We do, it…
Well, I think nobody uses them anymore because they aren't synthesized and the (readonly|readwrite) distinction is so clear.
Clean, Modern Objective-C
21–30 of 48 posts
Re: Clean, Modern Objective-C
#22I'm still learning Objective-C but it always bothers me a bit when a controller conforms to many protocols. Are there strategies to manage this (other than #pragma mark)? I really like point #4. I'd take that further and say that most "keyed access" classes should be wrapped in a more domain-specific wrapper class (thinking of NSUserDefaults, and the like). With regards to point #8, Apple actually recommends against…
Apple warns against it because it goes against key value coding I think. I am kinda on the I wish they had a consistent prefix for stuff. maybe it's just my feeble mind, but I like to have the code completion remind me of what's available. the sometimes inconsistent naming conventions in different classes makes it tough to remember all the nuances when you don't use them every day.
Re: Clean, Modern Objective-C
#23It's a nice little list. My one nitpick is that he referred to to the class extension [1] as an anonymous category and while it also has been called this it's generally documented as a class extension by Apple and so it makes sense to call that out so folks can go read about how it actually works. [1] http://goo.gl/zTu3nA
Re: Clean, Modern Objective-C
#24I'm not saying this makes instance variables preferable, but there is something to be said for minimising the number of places you need to look when trying to understand a snippet of implementation.
Re: Clean, Modern Objective-C
#25Yes its true, you can hack your way to to some idealized notion of objective C.
Accessing everything through properties is lame, and it sucks, and it only seems like a good idea if you use ARC because you think it will make it easier to find the retention bugs, it actually makes it harder.
Also properties are not the same as private members, although obj C trendists want them to become the same.
No, I disagree it takes you further away from object programming not closer.
The current trends in objective C are to hack the file syntax to make it seem like its more encapsulated and use properties to make ARC happy.
Both are wrong, obj C is a leaky abstraction. Too bad. You will never make it better by making your code harder to read and debug.
Yes in obj C inheritance sucks, protocols suck, constants suck, encapsulation sucks, and in the end if you know how to make something, it really doesn't matter. Stop obsessing on shit nobody cares about and build something.
Even with all your recommendations obj C is a bandaid. But falling off your skateboard can be fun. Live a little.
Re: Clean, Modern Objective-C
#26Re: Clean, Modern Objective-C
#27The ridiculous amount of effort that we have to go through to define private properties (just sheer amount of text around them) makes me miss the pre-property days... I still define iVars the old fashioned way. The whole language would do well to have some syntax sugar added akin to Java's private, public, protected for properties so we could just go @private NSString dog; @public NSString cat; ... Oh Wait! We do, it…
(On the other hand, defining properties in an anon category, instead of just plain old instance variables in the .m, seems pointless to me -- why have a layer of indirection for the class to access itself?)
Re: Clean, Modern Objective-C
#28 -(NSData*) myMethod:(NSString*)string;
It can really be argued both ways. We've hugged the type everywhere I worked.Re: Clean, Modern Objective-C
#29My points on Modern Objective-C: - Use MVVM and some method of bindings (e.g. ReactiveCocoa) [0] - Split up ViewControllers and DataSources [1] - Split up classes using Categories (I've seen so many blown up AppDelegates) - Use CocoaPods (this should be a given by now) - probably much more I forgot about... oh, and btw: those `@directives` go by the name of `literals` [0] - http://lmgtfy.com/?q=mvvm+objective-c [1] -…
-I've heard a lot about ReactiveCocoa recently, but I haven't had a chance to try it. Maybe I should. And maybe I will! - I'm super guilty of just handling everything in AppDelegate (notifications, URI schemes, etc.) I need to work on this. - CocoaPods are the greatest
Re: Clean, Modern Objective-C
#30Isn't it a bad idea to define private/protected properties in your implementation file? What if you want to subclass?