[Gambas-user] Financial program

[Doriano Blengino]

Jean-Yves F. Barbier ha scritto:
> Doriano Blengino a écrit :
>   
>>> Don't burry Cobol too fast: for banking *only*, this year will be around
>>> 5 milliards Cobol written lines (progression is an avg of 14% per year).
>>>   
>>>       
>> This is a proof that well designed things get a long life. Ok, cobol was 
>> invented exactly for that purpose - sadness is that nobody else seem to 
>> care much about those good things. And money is the gas (citation from a 
>> popular rock song :-)) of the world...
>>     
>
> This isn't really true: part of my family owns a company that sell pastry
> products (additives etc), their ERP run under UNIX and VT100 consoles
> and is entirely written in Cobol.
> Many mid to large companies use Cobol, and have problems to find programmers
> interested into this language - so there are good days left for those who care.
>   
I was intending that nobody steals good ideas from cobol. I know that 
cobol is still used but, I think, it is an old language. Dream: a really 
good language having some properties of cobol, and specialized GUI 
widgets where you bind the variable (with picture, limits, precision and 
so on) to a widget. Probably Java and Python are already able to do so, 
but they have other limits. Another problem I often face is that of 
preferences. I make a nicely customizable program, with lot of 
preferences, and for every preference I have to put a widget on a form, 
load its content from a file, rewrite its content to the file, and so 
on. Simply boring.
> ADA is also growing because of its very specialized variable definitions
> possibilities.
>   
A strongness inherited from pascal... I gave a look to many, countless 
languages, and only few met my own requirements - strong typization, 
good compiler checks, overloading and, of course!, OO model. One of 
these was Ada. But I rejected all C- and Java- flavoured. Irony again... 
C language is the one I use most...
>   
>> But on the side of the possible implementation in gambas, it is a really 
>> hard work. I thought a little about the question, not necessarily to 
>> propose changes in gambas, but to solve the problems in my application. 
>> A new class, which does rounding and formatting could work. Something 
>> like "dim subtotal as new currency(4,3)" would instantiate a variable 
>> with three decimals, stored as a long integer. "subtotal.picture" would 
>> return a string representation, "subtotal.picture(12)" would return a 
>> space-leaded string of 12 characters, with the formatted number aligned 
>> to the right. "subtotal.multiply()" would multiply numbers, and so on. 
>> Other methods would be required to interface to databases.
>> This is the OO way to implement what nando suggested. The problem is 
>> that calculi would be no more expressed in the usual, plain way, but in 
>> an unnatural way: "totalinvoice=amount+vat" would turn in 
>> "totalinvoice.set(amount, vat). After the first look, this could be 
>> something one can live with. But overloadable operators would be very 
>> appreciated to improve readability and, if impossible, compiler macro at 
>> least would help. You can walk around the problem as much as you want, 
>> and you finish with forcing a language to do things it never was planned 
>> to do. The same as complex numbers in C - you can use them, but what a 
>> bore! And, in fact, python supports complex numbers natively.
>>     
>
> This is even more complicated - ie: fr law say that precision of VAT rates
> is 4 decimals, and as I said before, some items can be invoiced with a
> large number of decimals.
> For VAT, more than 2 decimals had never been used but could be tomorrow;
> so this is an entire int2decimal processor to write (as you wrote, no more
> than 2 members to multiply because of that:(
>   
I am not sure to understand. If you take an amount with 2 decimals of 
precision, you can calculate VAT with 4 decimal precision:
    dim amount as new currency(8,2)
    dim vatrate as new currency(2,4)
    dim vat as new currency(8,2)
    dim total as new currency(8,2)

    amount.calculate(....)
    vatrate.set(18.55)      ' is this a percent, right?
    vat.calculate(amount % vatrate)
    total.calculate('amount+vat')

Now a few things should be considered. The variable VAT has a precision 
of 2 decimals, but by invoking vat.calculate(...), a variable with 
precision 4 is passed in, so the calculus is made on 4 decimals and, 
just before storing the result to VAT, the rounding to 2 decimals is 
made (and the rounding is another interesting piece...).
So we should have what we want: precision 4 in the rate, and precision 2 
in money's variables. Not sure what to do in the inverse operation... 
taking out a 18.55% vat rate from a total, should give a correct amount 
and vat which, added together, should give the total again... funny to 
say, but a little harder to implement... but this could be just another 
method (I call it "scorporo", but I don't know how to say it in english).
>   
>>
>> Uhm... I just readed back the mail about the "calculi" part. The 
>> "picturednumber" class could evaluate a string... so 
>> "totalinvoice=amount+vat" could be written as 
>> "totalinvoice.setTo("amount+vat")... double work, but double result... 
>> the only problem is that the compiler can not check for the correctness 
>> of the expression. Problems again.
>>     
>
> I lost too much time with things like that and now strongly consider
> to interface all calculation to Python and only keep GB as a GUI.
>   
Betrayer! :-)))

Why not interface to cobol directly, then? I don't think your way is 
viable - it would be even more "forcing a language to do things it never 
was planned for". I think you intend to call /usr/lib/libpython2.xx, 
perhaps through some wrapper class; interesting... may be this could 
solve the "expressions" issue...

Regards,
Doriano