[KUnitConversion] Question about overloading operators

[Albert Astals Cid]

El dilluns, 21 de novembre de 2016, a les 8:27:11 CET, Ander Pijoan va 
escriure:
> Hi Aleix,
> 
> I think at least the most desirable basic feature would be to have the
> math operators overloaded to be able to operate with Values. Something like
> 
> 
> Value operator +(const Value &other)
> {
>       Q_ASSERT( unit() == other.unit() );
>       return Value(  number() + other.number() , unit()  );
> }

Asserting in lib code is usually bad behaviour

> At least to be able to operate with same Unit Values.
> I have an application where I was calculating several routes. This week I
> started using KUnitConversion
> Values for the length, max speed and price of each of each road segment, in
> order to explicitly
> have the units "stored" within the value. But suddenly found I can't even
> sum two lengths because the
> + operator is not overloaded.
> 
> If further operations involving different units conversions want to be
> supported, probably some sort of
> equivalence structures would need to be created, but I havent think much of
> it. I was just asking about single
> Unit operations.

Given we actually have KUnitConversion::Converter, it wouldn't be that hard to 
try to implement, no?

Cheers,
  Albert

> 
> Cheers.
> 
> 2016-11-20 13:45 GMT+01:00 Aleix Pol <aleixpol at kde.org>:
> > On Fri, Nov 18, 2016 at 1:21 PM, Ander Pijoan <ander.pijoan at deusto.es>
> > 
> > wrote:
> > > Hi all,
> > > 
> > > First of all sorry if this email should be in another list.
> > > 
> > > I have a small question about summing, subtracting, multiplying...
> > 
> > Values.
> > 
> > > I see that the operators have not been overloaded. Should we extend the
> > > Value class and overload them or there is a more straightforward way of
> > > operating with Values?
> > > 
> > > Thanks in advance.
> > 
> > Hi Ander,
> > It's certainly tempting, I'm not sure how good it would work. Do you
> > have some kind of proof of concept?
> > It's something that sounds obviously good, but we need to make sure
> > doesn't become a mess. Knowing what's the problems we'd find could be
> > a good first approach.
> > Also what's your use-case? :)
> > 
> > Aleix