RE: [boost] Re: Numeric conversions lib comments

From: Rozental, Gennadiy (gennadiy.rozental_at_[hidden])
Date: 2004-03-24 01:57:36

> > 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.

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.

> 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
 
> > 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?

Gennadiy.