Don't burry Cobol too fast: for banking *only*, this year will be aro=
5 milliards Cobol written lines (progression is an avg of 14% per yea=
This is a proof that well designed things get a long life. Ok, cobol w=
invented exactly for that purpose - sadness is that nobody else seem t=
care much about those good things. And money is the gas (citation from=
popular rock song :-)) of the world...
This isn't really true: part of my family owns a company that sell past=
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 progra=
interested into this language - so there are good days left for those w=
I was intending that nobody steals good ideas from cobol. I know that=20
cobol is still used but, I think, it is an old language. Dream: a really=20
good language having some properties of cobol, and specialized GUI=20
widgets where you bind the variable (with picture, limits, precision and=20
so on) to a widget. Probably Java and Python are already able to do so,=20
but they have other limits. Another problem I often face is that of=20
preferences. I make a nicely customizable program, with lot of=20
preferences, and for every preference I have to put a widget on a form,=20
load its content from a file, rewrite its content to the file, and so=20
on. Simply boring.
ADA is also growing because of its very specialized variable definition=
A strongness inherited from pascal... I gave a look to many, countless=20
languages, and only few met my own requirements - strong typization,=20
good compiler checks, overloading and, of course!, OO model. One of=20
these was Ada. But I rejected all C- and Java- flavoured. Irony again...=20
C language is the one I use most...
But on the side of the possible implementation in gambas, it is a real=
hard work. I thought a little about the question, not necessarily to=20
propose changes in gambas, but to solve the problems in my application=
A new class, which does rounding and formatting could work. Something=20
like "dim subtotal as new currency(4,3)" would instantiate a variable=20
with three decimals, stored as a long integer. "subtotal.picture" woul=
return a string representation, "subtotal.picture(12)" would return a=20
space-leaded string of 12 characters, with the formatted number aligne=
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=20
that calculi would be no more expressed in the usual, plain way, but i=
an unnatural way: "totalinvoice=3Damount+vat" would turn in=20
"totalinvoice.set(amount, vat). After the first look, this could be=20
something one can live with. But overloadable operators would be very=20
appreciated to improve readability and, if impossible, compiler macro =
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 plann=
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 ra=
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 m=
than 2 members to multiply because of that:(
I am not sure to understand. If you take an amount with 2 decimals of=20
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)
vatrate.set(18.55) ' is this a percent, right?
vat.calculate(amount % vatrate)
Now a few things should be considered. The variable VAT has a precision=20
of 2 decimals, but by invoking vat.calculate(...), a variable with=20
precision 4 is passed in, so the calculus is made on 4 decimals and,=20
just before storing the result to VAT, the rounding to 2 decimals is=20
made (and the rounding is another interesting piece...).
So we should have what we want: precision 4 in the rate, and precision 2=20
in money's variables. Not sure what to do in the inverse operation...=20
taking out a 18.55% vat rate from a total, should give a correct amount=20
and vat which, added together, should give the total again... funny to=20
say, but a little harder to implement... but this could be just another=20
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=20
"picturednumber" class could evaluate a string... so=20
"totalinvoice=3Damount+vat" could be written as=20
"totalinvoice.setTo("amount+vat")... double work, but double result...=
the only problem is that the compiler can not check for the correctnes=
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.
Why not interface to cobol directly, then? I don't think your way is=20
viable - it would be even more "forcing a language to do things it never=20
was planned for". I think you intend to call /usr/lib/libpython2.xx,=20
perhaps through some wrapper class; interesting... may be this could=20
solve the "expressions" issue...