[boost] Re: Re: Numeric conversions lib comments

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2004-04-01 11:48:50

Rozental, Gennadiy wrote:
>>> In most part proposed design looks reasonable. I have only
>> one major
>>> IMO concern.
>>>
>>> Issue: (Major) Why traits are template parameter of
>> converter?  I've
>>> expressed my opinion in the matter before: Traits - as name suggest
>>> could not be policy. IOW should not be template parameters.
>> Traits are
>>> type specific and an ability to supply them independently to the
>>> primary type in most cases leads to invalid/too complicated design.
>>>    Traits are not only template parameters of public
>> converter class
>>> but many other classes. IMO all of them should use S and T
>> as template
>>> parameters instead.
>>>
>> I have to disagree.
>> Traits are used as policies in too many designs, including
>> the STL itself, and I don't see a problem with that. I agree
>
> I don't say I like it either. Major issue with basic_string design
> IMO is that char_traits is template parameter
>
>> that traits classes are type specific, but they are used as
>> policies precisely because of that: if the user of a
>> parametrized facility wants a different treatment for a given
>> type, she can't change *the* traits for the type, all she can
>> do is pass in a different traits as a policy.
>
> Here is how I see it. Trait is something type specific, IOW specific
> to
> type, IOW  uniquely defined by type. If you could provide trait along
> with the type as a template parameter, that mean you could change it
> independently from the type, IOW you could define different value for
> trait still using the same type. For example if you have component C
> defined like:
>
> template<typename T, typename Trait>
> struct C { ... };
>
> You could instantiate it like C<MyT,TraitValue1> or
> C<MyT,TraitValue2>. So
> as you could see trait value is not uniquely defined by the type.
>
> Proper design would be to have trait stand alone class, like this:
>
> template<typename T>
> struct Trait { value = ... };
>
> template<typename T>
> struct C { here we are using Trait<T>::value, where we used to use
> Trait. };
>
> Now if the user needs to define trait value (or change from using
> default value provided by most traits designs), she just need to
> define explicit/partial specialization for this type or types family.
>
What if there is already an specialization? That's the typical case with
standalone traits.

> On the other hand policy is something that is orthogonal to the
> primary type (actually in policy based design there may not be any
> primary type, but just an orthogonal policies), IOW you could use
> different policies in
> conjunction with the same type. And natural place for the policy is
> along with type in component definition among the template parameters.
>
Policies must be orthogonal between themselves, but not neccesarily w.r.t
the primary type(s).
In fact, many common policies (from common policy-based designs) are not.

>
>> If this were
>> not a policy, users would be stuck with the definition of the
>> default traits class. I agree that this opens a window to all
>> sort of problems in case a user plugs in an invalid traits,
>> but I think that should not constitute a reason for fixing
>> the traits into the converter. As always, "trust the programmer"
>
> So again Trait is not a Policy and let's not mix them
>
I disagree. A trait can _function_ as a policy IMO.

Well, I do follow your arguments but I'm still unconvinced.
A traits is type-specific, yes, but not necessarily _unique_.
You see it as unique, but why would it has to be like that?
It seems that that fundamental point of your argument is that traits are
uniquely defined by a type, and not just a type decoration.
If this were true, then I would agree, but I don't see why a type can't have
a set of "compatible" traits.

It would benefit your argument if you had some backup. That is, some
reference of others who think the same.

>>> 4. converter<>::convert converts only rvalue. Why?
>>>   IMO we need second operation that works with lvalues.
>> What if I want
>>> to convert int& into char&?
>> This requires the target lvalue as a parameter instead of a
>> return value. It could be done yes, but I don't see the
>> reason. Why would want to do that?
>
> For example for [de]serialization solutions. What is in your opinion
> is problem domain for numeric conversion?
>
Well, numeric conversions :-)
Whenever you need to convert between numeric types... there is no particular
problem domain for this general need.

In a [de]serialization framework I would expect types to be
serialized/deserialized the same, so I don't quite see the use case for a
numeric conversion here.

Fernando Cacciola
SciSoft