Hi guys, 2011/1/12 funlw65(Vasi) <[email protected]>: > What about a fully functional printf function?
and > On Jan 12, 10:45 am, Sebastien Lelong wrote: >> - format.jal not to print anything, but provide a way to eval things like >> "%s %4.2f". Functions would return formatted strings. The fact there are >> actually procedures with an output device as parameter keeps me get confused >> as it's just not involved in formatting data I dislike the many variables that need to be passed to format.jal and a format string might be a good alternatieve. It won't be possible to completely mimic fprintf (that would be the one to mimic, not printf or sprintf), since the number of parameters is fixed in jal. So maybe we need to take the format string concept and extend it for our use. Having said this, we can't use a string litteral as a procedure parameter, so this will be tedious to use. Also, this will become a huge library though. Note: iirc fprintf has no means to force a certain string within a specific/maximum number of characters. Format.jal does and IMO this is however a very usefull feature for displays and alike. >> - print.jal being responsible for actually printing things coming from >> format.jal. Maybe providing some helpers. Print.jal does some basic conversion (%s %d %x %b) and passes the result to the device (file handle). Format.jal supports more advanced formatting (like %4d and more). Much more powerfull, but also a lot more overhead (also in calling - long list of parameters at each use cluttering your sourcecode). >> I've already been explained several times, I still can't figure out why >> format.jal exists (or print.jal on the other side), except that format.jal >> was the original lib, and been re-written to create print.jal. If, in the >> way I understand lib features based on their name, print.jal is "just" about >> printing, then it doesn't add much value as it's just a matter of dealing >> with pseudo-vars. Another rebound then ;) Print does a conversion, but you can't control the output size, decimal point position etc. So it is a cut-down version of format. >> I would then understanding why format.jal would also take >> care of printing and print.jal would be removed, but I would also argue >> format.jal isn't properly named... Please save my sould and tell whether >> format.jal should really be named like that, or if it's a kind of print2.jal >> :) I doubt your soul need saving (and if so, if this would make the difference ;) Format.jal has lot of legacy, like you can specify the number of characters it may use, but does not include the decimal point (and sign iirc) into account. This is a bug, but one that are people are used to by now. Same applies for the interface. IMO it is best to refactor format.jal functionality and add it to print.jal. We can fix the quirks, change the interface and make it complete. Once we have a good working alternative, format.jal can be made obsolete. >> About formatting, what about a thousand separator char (quot, space, >> comma) and a decimal char (dot, comma) ? And what about fixed-point numbers, either based on the decimal separation (like it is now?!?) or on binary separation (like the single procedure that is in print.jal). Any ideas what would be the advantages from one over an other? Joep -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
