=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