The big performance gain for public instance vars seems to be due to use of prototype instead of having to use a priviliged method as needed for private instance vars.
It seems to me that private instance vars should be avoided (unless you only have one instance), and public properties should be used instead (maybe prefixed by an underscore to indicate they are not meant to actually be public).
Agree, disagree, any other opinions on this?
Yes, I disagree.
I believe that understandability of the code takes precedence over raw execution speed, and that such performance numbers are a curiosity more than anything else, until performance profile metrics of your actual code demonstrates the need for such improvements.
A great example of this has turned up just today, in the following article: Reducing my CPU load from 95% to 20%
I’d both agree and disagree with that. I agree that optimisations such as this are unlikely to make a noticeable performance difference in real life usage. However, I also think it is still useful to learn the most efficient ways to do things. Just because the way you write code at the moment isn’t currently causing you any issues doesn’t mean you shouldn’t try to learn better coding practices.
In terms of understandability of the code, I don’t see much difference between public and private instance vars. It could actually be argued that public instance vars are easier to understand, since you can easily tell they are tied to the current instance. (And you can indicate they are not meant to be public by prefixing with an underscore). Whereas with a private instance var, you need to look back up the stack to identify the scoping where they are defined.
That is a common convention, but can it be relied upon that other’s code will be following it?
■■■■ I’d be happy to see security, documentation and unit testing become more common practice let alone adherence to an established naming convention
Have you added in the maintenance cost in making that decision. The extra microsecond saved may be offset by a month of debugging due to a variable name clash.
I would have thought that you’re slightly more likely to have a variable name clash when using private instance vars as opposed to public properties? Of course, it depends on how your code is used.
If your code is a snippet or even a script that a user decided to concatenate with other (unencapsulated) scripts, then you could end up with a variable name clash when using private instance vars.
If your object is designed to be extensible and the person extending it doesn’t check the existing properties, then you could get a property name clash when using public instance properties.
Can I see a few code examples from you that demonstrate the danger of these clashes?
Thanks for correcting me on that, I just tested it and you are quite right.
I was wrong about the possibility of variable name clashes, it is not possible. I was thinking that if a variable name was previously assigned in the global scope, then the private var would actually be referencing that var, instead of being private. But that is not correct, the private var stays scoped to the object instance.
Not a problem - it’s great to see that you’re learning more about this side of things now.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.