Boost logo

Boost :

Subject: Re: [boost] [review] Conversion review starts today
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-09-02 18:58:56

On Fri, Aug 19, 2011 at 9:45 PM, Gordon Woodhull <gordon_at_[hidden]>wrote:

> Hi All,
> The review of Vicente Botet Escriba's Conversion library starts today and
> ends August 29.

> * What is your evaluation of the design?

Overall, I think it is designed well for its stated goal.

> * What is your evaluation of the implementation?

I didn't look.

> * What is your evaluation of the documentation?


> * What is your evaluation of the potential usefulness of the library?

Here is where I'm getting tripped up; I will expound below.

> * Did you try to use the library? With what compiler? Did you have any
> problems?


> * How much effort did you put into your evaluation? A glance? A quick
> reading? In-depth study?

I've been keeping up with other's review comments, and engaged myself a
little bit.

> * Are you knowledgeable about the problem domain?

I think so...?

> And finally, every review should answer this question:
> * Do you think the library should be accepted as a Boost library? Be sure
> to say this explicitly so that your other comments don't obscure your
> overall opinion.

To be honest, I'm very ambivalent. I'm hoping we can come to a consensus on
whether this library is appropriate for Boost or not.

Of course, "informal reviews" and discussion are also welcome.

Let me first say that the primary reason for deciding against outright
acceptance at the moment is purely philosophical and may be entirely
misguided. It seems to me that Conversion offers a generic solution to a
problem that rarely (if ever?) arises in generic contexts. This makes me
question its utility. Vicente, I would love to see an example where
Conversion solves a real conversion-between-unrelated-types problem (that
couldn't be solved in an equally simple or simpler way) within a generic
context; it's just difficult for me to imagine this, which might be entirely
my own mental block problem.

I think my perspective has been colored by my own experience in trying to
solve this problem. I, too, needed a framework within which to convert
unrelated (numeric) types, and built a framework similar (but, of course,
simpler) to what Conversion offers. Upon reevaluation, though, I concluded
that this framework was too inflexible and a visitor-based solution would be
more appropriate *for my application*. For me, I needed additional
*context* to convert between certain types, and I also wanted to support the
flexibility of different conversion *implementations*. In applications
requiring conversions between unrelated types, context and varying
implementations seem to me to be features that would at least occasionally
be desired, and there isn't really a convenient way for Conversion to
support that. Sure, you can wrap your "from" objects to tag them to select
the desired conversion implementation or to bundle them with the desired
context, but I wouldn't consider that very convenient and it certainly
reduces genericity (much better to have the implementation and context
dictated by the functor).

Aside from my philosophical objections, Conversion has the potential to
promote ODR violations, and this just seems like a Bad Thing. Sure, there
are other extendable operations (e.g., operator< or operator==) that could
cause ODR violations if defined for unrelated types by some 3rd party, but
Conversion seems unique in the sense that it provides an extension point for
an operation that *inherently* must operate with two unrelated types, with
the typical case that this operation is defined by some 3rd party
disassociated from the involved types. I don't think education is
sufficient to adequately mitigate this problem. But I don't know, maybe I'm
taking a corner-case problem and blowing it up into a big issue...

I apologize for not really discussing this earlier in the review, but I did
allude to it earlier in the week and I've really just been spending a lot of
time thinking if the above issues are real problems or not. I can't
convince myself that they aren't yet :/

I'll try to give specific comments related to the documentation and
interface sometime later, in case it is decided that Conversion should be

- Jeff

Boost list run by bdawes at, gregod at, cpdaniel at, john at