In a lot of our classes, such as Cartesian2/3/4 and Quaternions. We have helper methods such as getZero, getUnitX, getIdentify, etc… that always return the same value. For example:
Cartesian3.getUnitX = function() {
return new Cartesian3(1, 0, 0);
};
Since they are intended to be immutable types, it seems like bad performance practice to create a new one each time. Additionally, why not make these properties rather than methods?
Good topic. I actually made a change to replace all these functions with properties like
Cartesian3.UNIT_X = new Cartesian3(…);
I decided to revert it for fear that a user would change the property, and, therefore, break code everywhere. I discussed with Kevin and Scott. We were somewhat on the fence.
I don’t think users will directly modify these properties, but I could see a function taking a Cartesian3 modify them not knowing that the argument is constant by convention. Recently, Kristian changed all public-facing Cesium functions to treat Cartesian3 and similar types as if there were immutable, so the fear of accidentally changing these properties is less; however, a user could still do so in their own code.
We would like to see JavaScript property getters and setters get better performance, which would make this decision a no-brainier.
Given Kristian’s recent changes, and that I’ve used similar psuedo-constants elsewhere, e.g., BlendingState.ALPHA_BLEND, I am OK with this change if others, cough Scott cough, are on board. Matt, are you up for contributing it?
Patrick
Sure, I have no problem making the changes themselves if we can all
agree. I figured you would bring up the accidental modification
issue, but since it's impossible to really protect against those types
of things in Javascript (other than convention and documentation), I
don't think it's worth trying.
This would be a perfect use case for freezing objects, if it weren’t for the fact that freezing objects ruins performance (see http://code.google.com/p/chromium/issues/detail?id=115960)
Hopefully eventually this will get fixed, but in the meantime it seems OK to change to public properties and just document them as immutable.
On the plus side, that linked issue seems to indicate that freezing performance and JavaScript property performance are linked in their code. Maybe when they fix one, they’ll fix the other.
Given Scott’s OK and my OK, I think you are good to go. It’s up to you, but you probably want to do this in its own branch separate from viewer.
Patrick