[Kde-finance-apps] First appearance of Alkimia in the KDE SVN repository

[Klaas Freitag]

Hi Thomas,

> > > I just added some initial code to the Alkimia directory
> > > http://websvn.kde.org/trunk/playground/office/alkimia/ of the KDE SVN
> > > repository.
> > >
> > > It's not much, but I promised to work on the general object to represent
> > > values.
> > 
> > Which is cool, but also quite some complicated code, I hope I may say that.
> 
> Is it really complicated? I think this is some straight forward stuff.
Yes, it is, for a class that should be a "general object to represent values"
as you said before. 

I think this class is mixing different levels of abstraction and I would suggest 
to pull that from each other. IMHO the AlkValue should really only wrap the
gmp lib, and there should be a class that covers all the parsing and lets
say one that adds locale and money specific things to it. I really would not
see that all put together in one. 

If you agree on that, I can come up with a implementation example as code
of course only code speaks ;-)

> 
> > Its not that I can not understand it but I wonder if why we need that much
> > functionality in a base class. I am sure you have thought about that, but
> > let me ask some questions:
> > - The AlkValue constructor handles the '5 8/16' format. Where is that used
> > in practise?
> 
> We've seen it as price information in QIF files, something we want to import 
> from other applications.
Yes, but that should not be implemented in the most basic class I guess.

> > Wouldn't it make sense to have a flag that indicates if "dangerous"
> > operations such as the ones described above have taken place or not?
> 
> This can also be handled by the application or a derived class.
Which would duplicate code if the parsing is done in the base class.

> > And what about passing a KLocale to the constructor instead of just
> > the decimal sign? It could default to the default locale and other
> > information than just the decimal sign could be taken from it, for
> > example the toString method.
> 
> Sorry, no. The locale is not part of AlkValue. You have to be able to read in 
> data in any locale. As Alvaro pointed out already, there is a lot of knowledge 
> in the class that we learned the hard way in KMyMoney, like having a German 
> locale in the UI but the QIF file written by the German version of your old 
> finance app you want to get rid of is written using a US locale.
Sure, but note that there you can use multiple Locales in an app, as you
for example can write english invoices in a german running Kraft. I also went 
through  that excercise. And isn't the decimal char in the interface of
current AlkValue a kind of locale?
 
> The toString() method is not meant for UI purposes but for serialization. It 
> does not need locale information. I want to keep all the formatting in a 
> different spot.
Yes, agreed.

> Would love to see it being used in Kraft.
Sure :-)

regards,

Klaas