> On 03 Jun 2015, at 18:46, Mark Wright <blue.bucon...@virgin.net> wrote: > > >> On 03 Jun 2015, at 17:08, Alex Zavatone <z...@mac.com> wrote: >> >> >> One point I haven't looked at is, "if @properties are declared within the >> @implementation or the class extension, are they private? And if so, >> shouldn't they be preceded with an underscore and in that case, what does >> that make the ivar look like"? >> >> How are we to name private properties in modern Objective-C even though >> properties were/are inherently public (as I understand it) >> > > This is important and is all about *scope*. > > A class’s properties are only public if they’re in the header.
I think the OP's question was more about the naming conventions to avoid collisions (like not naming methods with a leading underscore). That hasn't changed. Getters and setters of properties (whether explicitly declared or by defining a property that synthesizes them) should not start with an underscore (For synthesized setters that's near-impossible, but for getters, defining a property whose name starts with an underscore would do the job, so don't do that), and since they're all registered in the same tables as all public methods, they're only conceptually private, but still outwardly accessible using valueForKey: etc.. Note that the naming rules are for keeping Apple's and your code from colliding, and for making your properties etc. work with frameworks conventions. So you're not supposed to use the underscore convention even for your private ivars, as Apple could add secret stuff to NSObject or any other base class you'd collide with. -- Uli _______________________________________________ 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
