Re: About iVars declaration and property
Re: About iVars declaration and property
- Subject: Re: About iVars declaration and property
- From: Conrad Shultz <email@hidden>
- Date: Wed, 16 Nov 2011 07:53:17 -0800
One other advantage to using properties over direct ivar access internally is KVO compliance.
Usually I prefer to declare properties backed by ivars of a different name, then use getters/setters everywhere except inside initializers and dealloc. Frees me from having to worry about willChangeValueForKey:, etc.
I do this even if I currently don't observe a property in order to foster forward compatibility.
(Sent from my iPhone.)
--
Conrad Shultz
On Nov 16, 2011, at 2:19, Quincey Morris <email@hidden> wrote:
> On Nov 16, 2011, at 01:00 , Don Quixote de la Mancha wrote:
>
>> Using properties significantly increased the size of my executable
>> file. If I had something like this:
>>
>> float a = [self foo: self.scale];
>> float b = [self bar: self.scale];
>>
>> I could cut down the size of my code quite a bit by caching the return
>> value of self.scale:
>>
>> float theScale = self.scale;
>> float a = [self foo: theScale];
>> float b = [self bar: theScale];
>>
>> Now just removing one of two getter calls by caching its result won't
>> have that much effect on binary size, but the other night I went
>> through my code to do the exhaustively. The size decrease was quite
>> significant.
>>
>> Using properties when a simple iVar would do is not justified. One
>> wants to use properties only when the generated code significantly
>> reduces the amount of work one has to do as a coder, for example by
>> automagically taking care of retain counts.
>
> Once again you're using a bogus argument. There's nothing wrong (in most cases) with using stack variables to "cache" property values or return values as you have demonstrated. However, these are not ivars.
>
> Within a class implementation, there's often nothing wrong with reading ivars directly. There's also nothing wrong with writing ivars directly, except that there is generally memory management to consider (though, I guess, not when you're using ARC).
>
>> Calling accessors is also quite slow compared to a direct iVar access,
>> because it has to go through Objective-C's message dispatch mechanism.
>
> If you're talking about access from outside the class (that is, from clients of the class), then the overwhelming consensus of developers who've being using Obj-C for a while is that properties are a huge win, because they provide useful encapsulation -- class implementation details, such as the backing store (aka ivar) for a public property, are hidden within the class's implementation.
>
> If you're talking about access within the class implementation, then the best approach depends on the circumstances. In many cases, the self-discipline of encapsulating property values yields greater robustness for subclasses, code readability, etc. In many other cases, internal encapsulation is of no benefit and direct ivar access is perfectly fine.
>
> I'll tell you, though, that (at least pre-ARC) the trend over the last several years has been strongly in favor of using the properties, for practical rather than theoretical reasons. Whether ARC might reverse this trend isn't obvious yet.
>
>> Focussing on interface is no excuse for weighty, bloated code!
>
> I'm not sure what exactly this has to do with "interface".
>
> One mantra that gets repeated a lot on this list is 'No Premature Optimization'. If the "weighty, bloated" accessors produce no significant *measurable* effect on your app, there's no reason to avoid them. If there is a measurable effect, and if the measurable benefits of optimizing your code outweigh the development costs of doing so, then by all means the optimized route is the way to go.
>
>
> _______________________________________________
>
> 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
_______________________________________________
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