Re: [boost] A design for geometric objects

Subject: Re: [boost] A design for geometric objects
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2008-11-15 13:15:39

>> mutable_ellipse_traits is not specialized for circle when ellipse traits >>is, and is_ellipse_concept would need a complementing >>is_mutable_ellipse_concept to complete this pattern.  We might specialize >>mutable_circle_traits for elipse because we can write circle data to an >>ellipse.

Bruno wrote:
>Yes indeed, this is the part that was missing to really handle the
>circle-ellipse problem. The design sounds good to me like that...

Sounds good, but there is a problem.

Consider the assign function:

template <typename T1, typename T2, typename T3>
struct requires_2 { typedef T3 type; };

//assigns anything that can provide a read only interface
//that models ellipse to anything that can model the mutable
//interface of ellipse
template <typename T1, typename T2>
typename requires_2<
        typename is_mutable_ellipse_concept<
                        typename geometry_concept<T1>::type>::type,
        typename is_ellipse_concept<
                        typename geometry_concept<T2>::type>::type,
        T1>::type &
assign(T1& lvalue, const T2& rvalue);
  
//assigns anything that can provide a read only interface that
//models circle to anything that can model the mutable interface
//of circle
template <typename T1, typename T2>
typename requires_2<
        typename is_mutable_circle_concept<
                typename geometry_concept<T1>::type>::type,
        typename is_circle_concept<
                typename geometry_concept<T2>::type>::type,
        T1>::type &
assign(T1& lvalue, const T2& rvalue);

So far so good, but if circle models immutable ellipse and ellipse models mutable circle it results in ambiguous function definition when you try to assign a circle to an ellipse because it can either view the circle as a read only ellipse or view the ellipse as a write only circle.

Basically, mutable traits should only be enabled for an object that is genuinely of that conceptual type and the immutable traits are sufficient to provide all desired copy conversion semantics.  This is sufficient to solve the problem.  I'm not 100% happy with the result because I have to write O(n^2) meta-function partial specializations given n conceptual types in a subtyping hierarchy.  SFINAE only works if substitution fails at the first level of instantiation, so I cannot create a hierarchy of partial specializations, but have to make every is-a relationship explicit.

Luke