Re: [boost] [GTL] - geometric template library - determininginterest

From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2007-10-10 15:38:25

Fernando wrote:
>I think that your design is based on unspecified behavior, and, given
that 
>there are equally valid alternatives, this is unjustified.

Upon reviewing the code it turns out that I use static_cast in the
implementation of mimic.  I must have used reinterpret_cast originally
and then changed it to static_cast after some code review with Gyuszi.
        static PointConcept& mimic() { return
static_cast<PointConcept&>(t); }
I am using autocast on the return value of yield to convert to the base
type
        T& yield() { return *this; }
Let's please rewind the conversation.

Using composition instead of inheritance would require reinterpret_cast,
as I understand it, so perhaps we should decide together if that is
really a change I should make.  Is the suggestion to use composition a
bad idea?  Is it based on unspecified behavior?

>But the C++ type system doesn't support "mimicing".
>These functions, by name alone, speak by themselves: they are unusual
>hacks. 
>(not the mentioned that yield is strongly associated with something 
>different)

The C++ type system doesn't support it *yet*.  I will probably change
the name to something more appropriate that relates it to the c++0x
proposal for concepts and concept_maps (map_to springs to mind,) doubly
so for yield.  I was expecting to change the names of just about
everything based upon the feedback I get from boost.

>Well, given the widely known, well documented and proven adaptation
pattern 
>commonly used here in Boost, which is ignificatly different from the
one >you 
>are proposing, you need to make an unusual effort and convince us that
this 
>"mimic" hack is a actually good example.

Again with the hack.  Let's not resort to four letter words. ;) 

>Keep in mind that submitting a library to boost not always means that
the 
>design/code is accepted in the form it was originally created.
>Sometimes, if not often, acceptance requires a complete re-design
and/or 
>re-implementation.

I've had that in mind from the beginning.  I am currently considering
switching from inheritance to composition, and plan to try that out
today to see if it causes any problems.  In the end it may be that I to
completely transform the library, but if there is nothing left of my
original idea because I adopt all of yours, what would be the point of
accepting it into boost?  It is my hope that there will be some
synthesis.  If it is just an issue of non-member, non-friend style being
in favor now vs. classes with a rich set of member functions I don't
think I would ever switch.  I am quite clearly encapsulating the data in
the data type and using the concept type to organize the set of
behaviors the concept is providing for that data.  Our use of the
language should be based upon an understanding of the benefits and
drawbacks of what we are doing, and not simply guided by a pseudo code
algorithm from one of Scott's books.

>That same happens with software, relying on facts that "ought to be
true" 
>when we don't really know is risky, and risks are taken only when there
is >a good reason for it. In your case, I don't see any.

Yes, it does happen with software.  The point of the anecdote is that we
ought to be able to do better than the monkeys.

Luke