=20
Don't burry Cobol too fast: for banking *only*, this year will be aro=
und
5 milliards Cobol written lines (progression is an avg of 14% per yea=
r).
=20
=20
This is a proof that well designed things get a long life. Ok, cobol w=
as=20
invented exactly for that purpose - sadness is that nobody else seem t=
o=20
care much about those good things. And money is the gas (citation from=
a=20
popular rock song :-)) of the world...
=20
This isn't really true: part of my family owns a company that sell past=
ry
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=
mmers
interested into this language - so there are good days left for those w=
ho care.
=20
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=
s
possibilities.
=20
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...
=20
But on the side of the possible implementation in gambas, it is a real=
ly=20
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=
.=20
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=
d=20
return a string representation, "subtotal.picture(12)" would return a=20
space-leaded string of 12 characters, with the formatted number aligne=
d=20
to the right. "subtotal.multiply()" would multiply numbers, and so on.=
=20
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=
n=20
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 =
at=20
least would help. You can walk around the problem as much as you want,=
=20
and you finish with forcing a language to do things it never was plann=
ed=20
to do. The same as complex numbers in C - you can use them, but what a=
=20
bore! And, in fact, python supports complex numbers natively.
=20
This is even more complicated - ie: fr law say that precision of VAT ra=
tes
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=
ore
than 2 members to multiply because of that:(
=20
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)
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=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).
=20
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...=
=20
the only problem is that the compiler can not check for the correctnes=
s=20
of the expression. Problems again.
=20
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.
=20
Betrayer! :-)))
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...
Regards,
Doriano