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: Alex Zavatone <email@hidden>
- Date: Wed, 03 Jun 2015 14:29:57 -0400
On Jun 3, 2015, at 1:59 PM, Uli Kusterer wrote:
> On 03 Jun 2015, at 19:09, Alex Zavatone <email@hidden> wrote:
>> On Jun 3, 2015, at 12:59 PM, Uli Kusterer wrote:
>>
>>> 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
>>
>> So, how are we expected to tell the private/public/ivar/property difference between all these variables we have to look at all day in an easy, clear and straightforward manner that doesn't require unnecessary thinking?
>
> I've never had a problem telling that difference, so I can't answer that question for you. If an object is complex enough that this becomes an issue, I'd probably split it up into several objects so it becomes easier and more obvious to grasp.
>
> -- Uli
Well, I wonder if starting private properties with a p as in pSomeAwesomeThing would be a decent-enough convention to start, because then an ivar for a private property would be _pSomeAwesomeThing.
This would leave public properties without any lowercase p (followed by a capital letter that starts the next word) and the ivar would be the same, but just starting with the _.
That would give us:
Public property: labelString
Public property's ivar: _labelString
Private property: pLabelString
Private property's ivar: _pLabelString
Does this seem to be a decent enough and not unweildy convention? While it wouldn't show any difference between a local or a parameter, it would certainly clarify the scope of these 4 cases.
Is this enough, or should we also take into effect locals and parameters? For locals, we could use my as a prefix since they would be local to the method, but that could end up as a PITA.
Also, how would this conflict with the recommended is prefix for booleans, if at all?
Thanks much, man.
Alex Zavatone
_______________________________________________
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