bearophile wrote:
The first part of this post was posted around October 2 2008, and
shows a lits of general bugs I have found in DMD/D.
This post lists several problems/bugs/limits I have found in the
write/writefln of D1.
[snip]
Thanks for taking the time to write them down. I was thinking you'd
write a number of actual bugs in write(f)(ln) instead of an infomercial
on put(r). Anyhow, these are good ideas that should be embodied in Phobos.
One note about the charter. I think it's slightly different.
The purpose of such functions: to print data and data structures on
the console.
I disagree. The purpose is to print data and data structures to any text
device, with the console as a particular case and a potential shortcut.
Such printing is mostly for the programmer, expecially during debug,
or for logging.
I disagree. Printing should work equally well for "real" tasks.
- Fast, possibly as fast as printf().
Cool.
- Unambiguous: the printed data must clearly show the type and
content of data.
I'm unclear on this. It would mean that if you print a short with value
1, you'd have to specify that it's a short. Or if you print a real
number valued at 1, you'd have to include the decimal point. Now I agree
that the decimal point (followed e.g. by zeros) is sometimes desirable,
but sometimes it's just not. So I'm rather confused about this
unambiguity principle.
I'd replace it with a flexibility requirement, e.g. that one can print
numbers in a variety of formats.
- Complete: all built-ins must have a good representation.
And what happened to "Extensible: user-defined types should be able to
define their own printing." toString won't cut it!
- Elegant and clean: to speed up the reading and have a good logs.
Great.
- A representation: when possible it can be useful to have an
alternative way to represent something in a more precise way. Python
tells apart the two usages: str() and its dual __str__ return a
readable textual representation, while repr() and __repr__ often
return a textual representation that put inside the code generates
the same object that has being printed. In dlibs I have found useful
create the same pair of functions (but in D objects have only one
toString(), so there's no support for a toRepr or something similar).
I think that's a great idea. One format for default printing, and one
precise format for serialization.
One thing that is sorely missing from this all is parsing. I think
library functions for formatted writing must be accompanied by functions
for formatted reading. (scanf does that for printf, but I think it's
doing a rather awkward job.)
The presence of parsing routines changes the charter a bit, e.g. in the
precise serialization mode you'd want to print an object in a manner
that makes it parsable later.
Andrei
