Re: Obj-C - your thoughts on hiding data members?
Re: Obj-C - your thoughts on hiding data members?
- Subject: Re: Obj-C - your thoughts on hiding data members?
- From: Quincey Morris <email@hidden>
- Date: Sun, 24 Jan 2016 17:05:02 -0800
- Feedback-id: 167118m:167118agrif8a:167118sE9uFcZHzC:SMTPCORP
On Jan 24, 2016, at 15:55 , Graham Cox <email@hidden> wrote:
>
> Do you generally think this is worth doing?
I’m not sure its *worth* doing, if you’re looking for a big pay-off, but I agree with Jens that I’d probably do it.
Sometimes it can be illuminating to see how small a public interface you need to expose. In other cases, it can serve as a kind of code smell to realize that the interface remains stubbornly large.
I’d also suggest that “modern” Obj-C code, private @interface () extensions tend to disappear completely. You no longer need them for forward-declaring file-local methods. You also — perhaps this might seem a bit controversial — no longer need them for most default (@synthesize-able) private properties. Since ARC and the non-fragile ABI, there’s really no reason to avoid instance variables in favor of private synthesized properties, except when there’s additional behavior that requires a getter or setter.
In most cases, the only @interface () extensions that remained in my classes were for private readwrite overrides of public readonly properties. Almost everything else just disappeared. It was a little eerie.
Note that ‘copy’ usually isn’t vital for private properties, because they’re mostly NSString values, and even if you set them to a NSMutableString, you rarely have any code that’s capable of mutating the string later.
You’d need a property for an 8-byte value that needs to be atomic, but those are pretty rare.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden