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 ------------------------------------------------------------------------------ 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