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: Alex Zavatone <email@hidden>
- Date: Sun, 24 Jan 2016 20:34:14 -0500
In this effort, what visual convention would you add to the private properties' names to indicate to the viewer that these are not public properties?
A prefix of _ is already used by the compiler to indicate the internal ivar backing properties so, what convention should be used for private properties?
On Jan 24, 2016, at 8:05 PM, Quincey Morris wrote:
> 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
_______________________________________________
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