I agree, and in this I was not careful with interpreting "specific internal representation", though I did qualify with "to some extent". I would rather discourage getters/setters in view that, as far as possible, a class should provide an interface by which it can perform its job without becoming like a POD struct that is a simple aggregation of data.
To return a reference, you need something to refer to. If you just return a value, you can compute it on the fly. If you get a value in a setter, you can store the result of a computation based on that, too.
I think that's the problem with this "attributes as object" method. It makes the class too much like a simple aggregation of data.
The solution would not be for the point to know about the play field. The solution would be to use a wrapper class for the point so as to enforce the restriction. This maintains the genericity of the point class while allowing the return by reference idea that this "attributes as objects" apparently requires.
We're talking about an object that contains sub-objects and wants to further constrain their domain. A game state class holding a play field and a player position wants to restrict the player position, which probably is a simple 2d or 3d point, to lie within the play field. The point is unlikely to have this restriction - it would have to know about the play field. That would make it larger than necessary and extremely non-generic.
So, if we would follow the Uwyn coding standard, the choice of point objects for member variables is a poor one, if we want to provide such accessors/mutators/setters/getters.
If that is the case, then you should use the second method listed by the coding standard I referred to.
I am trying to get away from returning references - hence why I mentioned creating wrapper classes for the primitives.
I doubt it, but the only way to know for sure is to test.
I know it takes roughly twice as much memory to store a wrapped primitive object vs. storing the primitive itself, and I'm OK with that. What I was interested in finding out is if having these values wrapped would significantly affect the run-time speed, given that they would be getting accessed hundreds/thousands of times a minute.
I would argue that both methods are proper OO design, if used sparingly. I would rather not maintain wrapper classes, so I would prefer the setter/getter method.
In other words, I care more about performance than proper OO design, but given the choice, I'd rather have my cake and eat it too.