Live data from Hacker News

Clean, Modern Objective-C

harlanhaskins.com

11–20 of 48 posts

Re: Clean, Modern Objective-C

#12
All of these things are something you use an automated formatter for, not regard as some kind of 'modern objc'. I guess people like to focus on pointless stuff like this because it's easier to worry about than whether you should use an eventbus or a delegate - you know, actual hard choices.

Stylistic stuff like this is not something you need to give rules for. Create an automated formatter, run it on your or others source files, and get back to solving real problems.

Re: Clean, Modern Objective-C

#13
post #12

All of these things are something you use an automated formatter for, not regard as some kind of 'modern objc'. I guess people like to focus on pointless stuff like this because it's easier to worry about than whether you should use an eventbus or a delegate - you know, actual hard choices. Stylistic stuff like this is not something you need to give rules for. Create an automated formatter, run it on your or others s…

You're right to an extent, but I don't think "Run your code through a formatter when you're done hacking it together" is a viable, maintainable, or scalable policy. Especially not for enterprise or team based workflows.

Also, #'s 1, 2, 4, and to a certain extent 8 are more questions of design pattern than 'style'.

Re: Clean, Modern Objective-C

#14
post #9
post #2

I'm surprised that he provides five versions of the method definition syntax and none of them are what Apple does and what I consider to be the standard: - (void)doSomethingWithParameter:(NSString *)parameter;

That is my preferred method as well, but I've seen a lot of templates use: -(void) doSomethingWithParameter:(NSString *)parameter;

When in Rome, do as the Romans do.

Re: Clean, Modern Objective-C

#15
I'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 naming functions starting with get... also, unless they are property getter overrides. (https://developer.apple.com/library/mac/documentation/Cocoa/...)

Thanks for the article.

Re: Clean, Modern Objective-C

#16
My 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] - http://www.objc.io/issue-1/

Re: Clean, Modern Objective-C

#17
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's just that nobody uses it anymore. http://stackoverflow.com/questions/4869935/objective-c-priva...

Well we have syntax sugar for iVars... I think it's so messy putting some properties in the header and some in the implementation file with a private category - come on we can't have better syntax than that?

Re: Clean, Modern Objective-C

#18
post #16

My 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

#19
It'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

#20

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.
Post reply on HN