be a teomporary at the interface because as I've just discussed with Brandon, there is the clear need to make things like polar points conform to Cartesian interfaces, which is incompatible with direct access to the data members. Since we already have to make a temporary we should cast at that point instead of having yet another temoporary and cast later on.
Maybe I'm misunderstanding something, but it seems to me that an algorithm that works with Cartesian coordinates will tend to be very inefficient if it has to convert to and from polar coordinates on the fly at every access.
Just to further this point : if we want to do geometry in spherical coordinates, then the point type cannot be homogeneous, especially if we wanted, e.g., to enforce dimensional correctness a la Boost.Units : cartesianPoint<si::length,si::length,si::length> vs. sphericalPoint<si::length,si::radians,si::radians> I understand that for most of the applications that people are considering, cartesian coordinates are dominant, but I can easily imagine a really cool game that accurately modeled relativistic effects to simulate space combat at near-light speed; to do that, you need a much more sophisticated and flexible system that is capable of dealing with Minkowski metrics rather than Euclidean... You could also have a game where players were constrained to motion on the surface of a 3-sphere...seems like there are a bunch of possibilities that thinking in a cartesian straitjacket precludes. Matthias