Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clean, Modern Objective-C

harlanhaskins.com

Post reply on HN
Print view View original

31–40 of 48 posts

Re: Clean, Modern Objective-C

#31

Post by greatsuccess »

archagon wrote: post #28

In response to point #3, my counter-example is that when you list a method's arguments or return type, the parentheses include the star. In other words, the star does not "belong" to the variable in that particular case. -(NSData*) myMethod:(NSString*)string; It can really be argued both ways. We've hugged the type everywhere I worked.

I agreed with you for about ten years, and then I stopped doing that because of the OPs example but also because idiomatic c and c++ are written this way and I just decided to stop swimming upstream after reading enough of it.

But it can be very confusing when dealing with dereferences. So I feel you there. Doing C for 15 years you just get used to it.

Re: Clean, Modern Objective-C

#32

Post by archagon »

chromejs10 wrote: post #30
archagon wrote: post #26

Isn't it a bad idea to define private/protected properties in your implementation file? What if you want to subclass?

You'll have to redefine the properties in the subclass's class and specify @dynamic so that it knows the properties were synthesized in the parent class

I've experimented with putting the category in a private, implementors-only header file and it seemed to work fine. But I'm not sure if that's canonical.

Re: Clean, Modern Objective-C

#33

Post by bitserf »

dilap wrote: post #27
WoodenChair wrote: post #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…

Having public things be in the header and private things in the .m seems exactly right! The header should only expose the public interface, not the implementation details, no? (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 ?)

I'm a heavy user of properties in other languages like C#, but in Objective C, to define the anonymous category with all the property ceremony and verbiage, feels...excessive...if all you need is some private state, and you don't care about generated accessors or KVO.

Why are ivars bad, exactly? They're a lot more succinct if you don't actually need what properties give you.

Re: Clean, Modern Objective-C

#34

Post by chromejs10 »

greatsuccess wrote: post #29
lyinsteve wrote: post #18

Earlier quoted context omitted.

-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

Build some stuff with Reactive Cocoa before you jump on that bandwagon. It pollutes the stack of everything it touches and its not very useful unless you use it pervasively...

I agree completely. Its use case is highly specialized and all it does is make a bunch of code nicely split up into methods and crams it into fewer methods with a ton of blocks. Even the example of "before" and "after" on the github page shows that how complicated it makes things look.

Re: Clean, Modern Objective-C

#35

Post by greatsuccess »

chromejs10 wrote: post #30
archagon wrote: post #26

Isn't it a bad idea to define private/protected properties in your implementation file? What if you want to subclass?

You'll have to redefine the properties in the subclass's class and specify @dynamic so that it knows the properties were synthesized in the parent class

And thats all bad and why inheritance and encapsulation in obj C are kind of rough on you.

But on the other hand, it discourages something thats overused in other languages. Inheritance!

Obj-C would do well to find a better composition mechanism to make most of the inheritance issues a secondary concern.

Re: Clean, Modern Objective-C

#39

Post by oesmith »

lyinsteve wrote: post #13
RyanZAG wrote: 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'.

I think many go programmers would disagree with you, and C++ programmers who've discovered clang-format too.

Bikeshed discussions about formatting quickly go out the window when you have an automated tool that can settle all arguments.

Re: Clean, Modern Objective-C

#40

Post by overcyn »

jsankey wrote: post #24

This and the linked guides claim there is no advantage to using instance variables (preferring properties), but I see at least one advantage: simplicity. When you're reading code that uses an instance variable you know exactly what it's doing, you don't have to check the attributes of the property, or the getter/setter implementation, or think about any KVO going on. I'm not saying this makes instance variables prefe…

Exactly!!!! So much of objc programming is about maintaining internal state. Dot syntax and automatically synthesized properties just obfuscates whats actually going on.

IMO you should always be accessing the ivar directly unless you have a specific reason not to.

Post reply on HN