On 03 Jun 2015, at 19:06, Alex Zavatone <z...@mac.com> 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 (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