Re: Obj-C - your thoughts on hiding data members?
Re: Obj-C - your thoughts on hiding data members?
- Subject: Re: Obj-C - your thoughts on hiding data members?
- From: Rick Mann <email@hidden>
- Date: Mon, 25 Jan 2016 15:53:26 -0800
> On Jan 25, 2016, at 15:32 , Alex Zavatone <email@hidden> wrote:
>
>
> On Jan 25, 2016, at 5:52 PM, Greg Parker <email@hidden> wrote:
>
>>
>>> On Jan 24, 2016, at 3:55 PM, Graham Cox <email@hidden> wrote:
>>>
>>> In Objective-C 2, data members can be moved into a @interface MyClass () section which lives in the .m file, rather than in the header file as in the classic case. This makes sense - those data members are typically part of the private implementation details of a class and not part of the public interface.
>>
>> Even better, you can move them to @implementation itself. No need for the extra class extension if everything is used inside a single file.
>>
>>
>>> But is it worth updating older code to follow this convention? I’ve updated a lot of older code to declare @properties instead of classic getters and setters, and that definitely improves readability. This is a further step I’m contemplating but the benefits are less clear. Do you generally think this is worth doing?
>>
>> A performance gain. @public and @protected ivars each create an exported symbol; @private and @package ivars do not. Reducing symbol exports can improve launch time and stripped executable size. Ivars declared in @implementation or a class extension @interface are @private by default. Ivars in the primary @interface are @protected by default. Therefore you should either move your ivars out of the primary @interface, or leave them in @interface but explicitly declare them @private or @package.
>
> Wow. This is awesome.
>
> It also leads directly to the question I had previously, “what are the proper naming conventions for these?”
>
> Since a lot of Cocoa relies on visually identifying if the word in question starts with a capital letter, a lowercase letter or an _ to communicate to the programmer the exact nature of the thing they are looking at, what are the proper conventions for these?
>
> Yeah, the ivar for an @property called myThing is _myThing and we can know that by looking at it with our eyeballs. How do we extend that type of visual exposure of information of the “thing” being inspected in a similar manner?
>
> Do we have any standards for this?
>
> If not, should we create some?
I'd suggest it's not necessary. What I like about member naming conventions has to do with identifying their scope. In my personal programming style, I name things with a single lower-case letter to make their scope known; that makes it much easier to track down a variable and understand its use (more useful than type, which is generally obvious and not actually the important in context, and which can change over time). I'd suggest that accessibility of a symbol is not all that important when looking at the code, either.
FWIW, my convention comes from PowerPlant days (and hence, C++):
• Local variables start with a lower-case letter. Local variables are declared as close the point of first use as possible.
• Parameters start with "in", "out", or "inout", depending on their intended use.
• Member variables (ivars) start with a lower-case "m" (rather than an underscore). Their corresponding property names delete the prefix character and start with a lower-case letter.
• Static member variables (which don't really exist in Obj-C, but which I implement as file-scope variables) are prefixed with "s".
• Constant variables, either via "const" keyword or #define, are camel-case and prefixed with "k"
• Preprocessor flag are camel-case and prefixed with "q".
• Preprocessor macros are treated like free functions (camel-case), and implemented as inline functions whenever possible.
Knowing the *scope* of a variable in unfamiliar or long-forgotten code, I find, helps me understand what's going on more than any other piece of information.
--
Rick Mann
email@hidden
_______________________________________________
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