The rationale that something is possible, therefore it should be done is no rationale at all.
--Michael Fawcett wrote:
This is a gross misrepresentation of what I said. I said the end-user cares, *and* it's doable, so it should be done. You only took half of what I said.
You are right, I apologize.
Heterogeneous coordinates in the interfaces and internals of algorithms is incompatible with runtime accessors to coordinates and high order constructs.
Algorithms that need runtime indexing should require that concept.
All of my algorithms use runtime indexing, so that might slant my point of view slightly here.
I don't see any value in carrying the individual coordinate data types through the interface into the algorithms.
They're already present at compile-time. No extra work required.
Well, yes and no. If I want to have a template <int axis> coordinate_type get(const point_type& point); accessor function I need to go through a lot of work to rewrite it as template <int axis> typename coordinate_type<axis>::type get(const point_type& point); and the user needs to go through more work to provide both template<int axis> struct coordinate_type<axis> { typedef int type; } and struct general_coordinate_type { typedef int type; } and will generally be puzzled about why the geometry library is so complicated to use.
Why not cast them up front in the user-provided accessor functions and let the user who knows and cares what casting they want to get control that. Having one coordinate data type within the algorithms *does* make the implementation of those algorithms simpler and simpler is usually something worth pursuing.
Because the casting and the temporaries it creates is not free, neither in terms of speed or storage.
You will have to cast at some point to use the value, why is it more expensive to cast up front rather than at the last possible moment. Assuming the value is going to be used more than once by the algorithm it will be cast more than once. Better to factor that to the front. A smart compiler would actually do that for you. Futhermore, there has to 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. Luke