Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.
Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.
- Subject: Re: Understanding the "declaration of instance variables in the interface is deprecated" warning.
- From: Uli Kusterer <email@hidden>
- Date: Wed, 03 Jun 2015 19:57:28 +0200
On 03 Jun 2015, at 19:06, Alex Zavatone <email@hidden> wrote:
> On Jun 3, 2015, at 12:46 PM, Mark Wright wrote:
>
>> This is important and is all about *scope*.
>>
>> A class’s properties are only public if they’re in the header.
>
> Exactly.
>
> With that said, why do we not have a convention with properties declared within the .m file for showing that they are private but not ivars?
>
> If we do, what is it?
It's historical. In ye olde days (32-bit MacOS and NeXT before it), the compiler needed to know what ivars an object had to be able to allocate memory for it. These days (i.e. on the "modern runtime" that you have on 64-bit Mac and all flavors of iOS), it doesn't need that information anymore (the size needed for an object's ivar storage and, more importantly, the offsets of individual ivars inside the storage is conveyed differently).
Now that that isn't needed anymore, Apple recommends declaring properties that clients of your class are supposed to mess with in the header, the others (e.g. ones that are an implementation detail or only of interest to subclassers) in your implementation or a header that you indicate as containing stuff for these purposes (e.g. by naming it MyClassSubclassers.h).
The only convention I know that some programmers use is a prefix, usually the same as the class prefix, but lowercase and with an underscore separating it from the method name (e.g. uli_frobnitzTheFrobozz:). The reason few people use this is because most people find it harder to read in method invocations, and most method names are probably expressive enough not to make sense for the usual NSObject, UIView or UIViewController base classes, so collisions are unlikely. Also because they look a bit daft in setters when used with properties (like setUli_frobnitz:).
-- Uli
_______________________________________________
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