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 ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user