Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
John-Lluch opened this issue Jan 15, 2014 · 8 comments
Closed

Comments

@John-Lluch
Copy link

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"

@ghost
Copy link

ghost commented Jan 15, 2014

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
Copy link

mirekp commented Jan 15, 2014

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 notifications@github.com 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
Copy link

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 notifications@github.com 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 notifications@github.com 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
Copy link
Contributor

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
Copy link
Contributor

ndubbs commented Jan 17, 2014

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!

@ndubbs ndubbs closed this as completed Jan 17, 2014
@John-Lluch
Copy link
Author

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.

@ghost
Copy link

ghost commented Jan 17, 2014

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
Copy link
Author

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants