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: Greg Parker <email@hidden>
- Date: Mon, 25 Jan 2016 14:52:13 -0800
> 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.
--
Greg Parker email@hidden Runtime Wrangler
_______________________________________________
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