[Gambas-user] Financial program

[Doriano Blengino]

Jean-Yves F. Barbier ha scritto:
> Doriano Blengino a écrit :
> ...
>   
>> while only 2% of them want to use financial capabilities. So, that 2% 
>> must live with a language not very suitable for accounting". "Use long 
>> integers, divide them, use format$()..." is the reply from Benoit. Does 
>> someone remember the Cobol? With a simple declaration "picture 99.9999" 
>> it created a datatype and managed all the roundings and conversions on 
>> that datatype; this was the power of that language. I don't say that 
>>     
>
> 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...
>> gambas should implement this, but it would not hurt... it is a matter of 
>> choice; I understand that this kind of things is difficult to implement 
>> (or, who knows... with OO programming... but the really hard part is the 
>> mixing of different types in the same expression).
>>     
>
> I totally agree: this also would make the difference between a nice GUI
> maker and a mature graphical language.
> That's what I was trying to explain (with no such fortune though.)
>   
You was more lucky than me, because you was replied "perhaps in gambas 
4"; when was my turn to ask, Benoit replied "I will not implement 
currency type in gambas". Stop. What an irony... someone who hates money 
and financial programs (me) has to be knocked down for a request about 
currency...

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.

I must experiment a little with this idea, but I suspect that new 
classes for every textual gui element would be needed, and it is this 
part which scares me. I wrote some new components for this, and they 
work, but they have some quirks I don't understand well. And... I really 
hate accounting programs...

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.

Regards,
Doriano