> On 03 Jun 2015, at 18:59, Uli Kusterer <witness.of.teacht...@gmx.net> wrote:
> 
> On 03 Jun 2015, at 19:09, Alex Zavatone <z...@mac.com> 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


For what it’s worth, I’ve never had that problem either.  Most of the time 
self.whatever is used for property access, _whatever is used for ivar access 
and that’s about it.  Public or private property doesn’t matter within the .m 
file since they’re both properties of the class.  Which is which is a result of 
the overarching design of the class at a higher level.

The rest is taken care of within the IDE in some manner or can be quickly 
checked if really needed.

The only potential problem is ivars that don’t have the leading underscore.  My 
own declared ivars *are* declared with the underscore so I typically don’t see 
that problem (the IDE’s colouring helps here I suppose since they tend to look 
different).  I believe Uli is mistaken on this point, I’m pretty sure Apple 
actually recommends prefixing your own ivars in this manner (hence the way auto 
property synthesis works), it’s *methods* that generally shouldn’t be prefixed 
with an underscore (but I do that on occasion too since the naming is generally 
specific enough to render collisions vanishingly unlikely).



_______________________________________________

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

Reply via email to