What's the point on using properties instead of instance variables?

[kodecocodes]

What's the point on using properties instead of instance variables?

See my comment on issue 42. Same answer applies here. Basically, just to pick one.

Also, as for your argument that properties are "MUCH" slower, I agree that they are slower, but much like writing assembly code is usually more trouble than it's worth nowadays, avoiding properties probably won't improve the overall performance of your app. And it certainly won't improve the performance of the short tutorials we usually post here, with the possible exception of some OpenGL-heavy tutorials. In those cases, we could use instance variables and explain why.

Thanks for your input!

[mirekp]

I think the main advantage of accessing a variable via property is that you can easily override its setter/getter (for example for a purpose of lazy instantiation). Obviously, that can only work reliably if you access consistently the variable using the getter.

Mirek

On 15 Jan 2014, at 20:54, John Lluch Zorrilla [email protected] wrote:

On the guide you state "Private properties should be used in place of instance variables whenever possible. Although using instance variables is a valid way of doing things, by agreeing to prefer properties our code will be more consistent."

Property accessors are MUCH slower than instance variable access. So why do not allow direct declaration of variables for private use in a class?. What do you mean by "consistent"

—
Reply to this email directly or view it on GitHub.

[casademora]

You’re not going to significantly impact the speed of your app by using properties in classes. There are cases where you need real time responsiveness and will need to drop down to language with less overhead, but thats a case where your whole framework needs to be using C (like audiounits, and core audio) not your classes.

Private properties give your classes so much more flexibility in its design that it’s worth the few microseconds of extra speed cost. Avoid using the instance variable accessors because you don’t benefit from all the awesomeness of object oriented programming, message passing, abstraction et. al.

On Jan 15, 2014, at 3:03 PM, mirekp [email protected] wrote:

I think the main advantage of accessing a variable via property is that you can easily override its setter/getter (for example for a purpose of lazy instantiation). Obviously, that can only work reliably if you access consistently the variable using the getter.

Mirek

On 15 Jan 2014, at 20:54, John Lluch Zorrilla [email protected] wrote:

On the guide you state "Private properties should be used in place of instance variables whenever possible. Although using instance variables is a valid way of doing things, by agreeing to prefer properties our code will be more consistent."

Property accessors are MUCH slower than instance variable access. So why do not allow direct declaration of variables for private use in a class?. What do you mean by "consistent"

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

[ColinEberhardt]

This is a Pandora's Box - please do not touch!

I'd recommend reading the 113 comments attached to this issue #5 where we discussed properties vs. instance variables at great length. Very great length. Very very great length.

The upshot is, we discussed, we debated, we didn't agree, we put it to the vote and went with the majority. The coding style remains a guideline, so deviations are permitted. Except in the case where authors work towards a single work, such as a book, here consistency is more important and as a result the style guide is enforced with more rigour.

I have my own personal preferences (which can be found in the 113 comments!), but I am happy to go with the majority.

• Colin E.

[ndubbs]

The term "consistent" is used to describe the use of private properties throughout tutorials and books.

There is not an exorbitant amount of time lost when using private properties. Please read the Big Nerd Ranch article on performance: http://blog.bignerdranch.com/4005-should-i-use-a-property-or-an-instance-variable/

This decision is going to stick. As @ColinEberhardt mentioned, it was discussed throughly!

[John-Lluch]

Hi ndubbs, thanks for your answer. I must of course stick with the majority, I actually entered this discussion after #5 was closed, so there's nothing I can argue at this time. The Big Nerd Ranch is obviously totally biased as it is only showing half of the picture: Getting self.someOtherViewController replaced by _someOtherViewController as an example of why not using ivars, and using a for loop computing a float addition as an example of improving performance with ivars, and forgetting in such case the code involved in the getter, or not performing any benchmark on setters? Oh well, that was not obviously my point.

I suppose the next big think will be favoring this:

- (CGPoint)bottomRight
{
    return CGPointMake(self.frame.origin.x + self.frame.size.width, self.frame.origin.y + self.frame.size.height);
}

over this:

- (CGPoint)bottomRight
{
    CGRect frame = self.frame;
    return CGPointMake(frame.origin.x + frame.size.width, frame.origin.y + frame.size.height);
}

I'm sorry but I can't stand that kind of coding that for no reason AT ALL produces twice the amount of code which is 10 times slower.

Case closed.

Actually, we would probably favor this:

- (CGPoint)bottomRight
{
  return CGPointMake( CGRectGetMaxX(self.frame), CGRectGetMaxY(self.frame) );
}

Apple recommends using those macros to access rects, rather than using the struct fields directly.

But I get your point. You'd prefer fewer property calls, especially when they are all to the same property. No one would be against your second example.

Thanks!

[John-Lluch]

Thanks again for your answer, I would rather have this though:

(CGPoint)bottomRight 
{ 
    CGRect frame = self.frame;
    return CGPointMake( CGRectGetMaxX(frame), CGRectGetMaxY(frame) ); 
}