Re: [boost] [review] Conversion review starts today

Subject: Re: [boost] [review] Conversion review starts today
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2011-09-04 13:59:09

Le 04/09/11 11:04, Jeffrey Lee Hellrung, Jr. a écrit :
> On Sat, Sep 3, 2011 at 12:47 AM, Vicente J. Botet Escriba<
> vicente.botet_at_[hidden]>  wrote:
>
> Comming back to string<->type conversions. These kind of conversions can not
>> be used with the library as a string and a type doesn't model the same
>> concept.  We need to interpret the string in a certain way to make an
>> instance of a type and vice-versa. Coerce and Lexical Cast give some answers
>> to this problem. One of my errors was to try to respond with my library to
>> this problem through a generic conversion.
>>
> I agree.  It is certainly much more reasonable to explicitly reduce the
> scope of your library down to interconversions between types which are
> somehow concept-related.  As you've surmised, the big problem with string
> <->  type conversions and similar is an absence of universal semantics.
Yes. I think all these cases are related to the fact the concrete types 
don't model the same concept, as they are not too strong. Once you have 
they model the same concept it seems natural to expect the the 
conversion is unique.
> An alternative I didn't considered while writing this library, as you and
>> others have suggested, is passing a functor that knows how each one of the
>> needed conversion can be performed. While this solves the ODR issue, it
>> forces the user to build the functor which could not be an eassy task for an
>> end user. I need to take sometime to experiment with this design in odr to
>> see its advantages and liabilities.
>>
> Yes, I can imagine a lot of repeated boilerplate from multiple users
> defining their own functors to do the same conversions.  But I don't see any
> other way around the ODR issue without outlining strict usage patterns
> within the documentation of Conversion.  I don't feel like Conversion's
> framework is currently very scalable: at some point, a user will want to use
> libraries C and D, each of which define conversions between typeA and
> typeB.  At best, this will be detected at compile time, but regardless,
> you're hosed.  Can we design Conversion to prevent this collision from
> happening?
I don't know if you have read this sectionHow can libraries define and 
use conversions between unrelated types? 
<https://svn.boost.org/svn/boost/sandbox/conversion/libs/conversion_ext/doc/html/boost/conversion/users_guide.html#boost.conversion.users_guide.tutorial.proto> 
(https://svn.boost.org/svn/boost/sandbox/conversion/libs/conversion_ext/doc/html/boost/conversion/users_guide.html#boost.conversion.users_guide.tutorial.proto).
> What if the framework defined by Conversion was less universal, and more
> local to the library which wishes to utilize it?  I know that suggestion is
> very vague and I don't really have a good idea for what that would look
> like.  Maybe if we went strictly with conversion functors and Conversion
> provides facilities to make such functors easy to define and use...?
This could be a possibility, but I don't like too much the additional 
parameter. I need to think more about.
>> The kind of conversion I needed to apply didn't had any need of a context.
>> I don't like the grap idea too much and I have not used it in concrete
>> examples.
>>
> s/grap/wrap, I assume?
Yes :)
>
>
>>   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...
>>>
>> Of course, I agree with the ODR violation promotion, and the library can't
>> provide a clean mechanism to avoid it.
>> I guess this will be at least useful to show that this kind of issue can be
>> promoted by other libraries as well (e.g. libraries that need to make
>> concept maps, ...)
>>
> Maybe the ODR issue can be solved with some "out-of-the-box" thinking...
>
>
Note that I said the library doen't provide a CLEAN mechanism, not that 
the library doesn't provides one (see the previous link). I hope someone 
could improve it in a near future.

Thanks for your commets,
Vicente