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 <graham....@bigpond.com> 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 (Cocoa-dev@lists.apple.com) > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com > > This email sent to z...@mac.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
