> 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. The .h header file describes the class’s public facing interface. You might consider this the ‘outside’ of the class. The .m implementation file describes the class’s internal private inner workings. You might consider this the ‘inside’ of the class. The header is used to advertise what is accessible to other objects (often called ‘clients’). This being properties that can be set, properties that can be queried and methods that can be called (really ‘sending messages’). The implementation however is considered completely out of bounds and is private to the class. So, if you declare @properties inside the @implementation then, yes, they are private. However, you don’t need any special naming conventions or extra underscores or anything like that, *they’re only accessible by code inside the .m file itself.* Now, as the programmer yourself, the code you’re writing inside the .m file is the same sort of code you’re writing everywhere else so it’s up to you to always keep in mind this concept of scope. An example: if you want an internal object that you might be wanting to get and set frequently *but is not part of the public facing side of the class* you’d declare a @property just for use inside the class. On the other hand, maybe there’s an object you need inside the class but you only set it up once, perhaps an NSUndoManager for example, then there’s no point making it a property so instead you can declare this as an ivar in the @implementation block, set it up in the init method and just refer to it whenever it’s needed. _______________________________________________ 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
