Don wrote:
bearophile wrote:
This post is mostly for Andrei.
I have played with D2 a bit; probably I'll need months to digest it
and its new Phobos2. While I explore Phobos I'll probably post some
comments/bugs around here.
After reading this:
http://blogs.msdn.com/vcblog/archive/2009/04/22/decltype-c-0x-features-in-vc10-part-3.aspx
I have tried to write a toy implementation of it in D2 (not using
Phobos2 yet):
import std.stdio: writeln;
import std.string: format;
struct Watts {
...
Two things to improve:
1) All structs must have a default built-in opString, a good
representation can be:
StructName(field_value1, field_value2, field_value1, ...).
It's not a perfect textual representation, but it's WAY better than
the current one (currently it shows just the struct name).
(Printing the module name before the struct name is bad, most times is
just noise)
No!
<rant>
toString() is one of the most dreadful features in D. Trying to slightly
improve it is a waste of time -- the whole concept needs to be redone.
It's horribly inflexible, tedious, and hugely inefficient. What more
could there be to hate?
- the object being called has no context. It doesn't know what format is
desired, for example.
- you can't emulate formatting of built-in types, NOT EVEN int! You
can't do left-align, pad with zeros, include + sign, display in hex.
- it's got no stream concept. Every object has to create and manage its
own buffer, and nobody knows if anyone actually needs it.
It ought to be at least as simple as:
struct Foo(A, B, C){
A[10] a;
B b;
C c;
void toString(Sink sink){
foreach(x; a) sink(x);
sink(b);
sink(c);
}
}
... but it's not, you have to create a silly buffer to put all your
strings in, even if there are 200 million of them and your giant string
is just going to be written to a file anyway.
I'd like to see version(debug) {} put around Object.toString(). It's a
deathtrap feature that's got no business being used other than for
debugging.
</rant>
First of all, printing stuff "struct.toString()" style is for two things:
o Debugging
o Small throwaway code snippets
The latter mainly being for two purposes:
o Testing quick concepts, trying out library functions, etc.
o For the newbie, when he's learning D, but not output formatting.
No "Real Program" uses this, because there you typically do proper
formatting of the output anyway, and almost never print entire structs
or objects as such. Instead, rather the information that they represent.
Second, since we have cool stuff in D, like templates, boxing, and other
advanced things, then compared to them, it should not be a big deal to
have automatic creation of toString for structs and objects. (This could
even be on-demand, i.e. unless called, the toString is not created for
an object/struct.)
Since the purpose of toString here is not Grand Style, it should suffice
to just recursively print the struct with its possible substructs, etc.
This would relieve the programmer from the entire extra work, and it
would also make objects look tidyer in source code.
Actually, this way, it would become trivial to print stuff:
myFancyStructWithInnerStructs st;
myRealCoolObject mo;
int i;
float f;
string s;
writeln(st,mo,i,f,s);
Here the programmer couldn't care less about looks and formatting, *as
long as* the output is legible and clear.
And what luxury -- not having to update the toString function each time
you change the class' structure! (That's a relief in the early stages of
the program, when everything is alive and fluid, before one settles on
the optimum structure.)
Naturally, if the programmer *does* supply a toString() method, then
that'd be used instead.
--------
Another way to do this would be to have a template function that writeln
(but not writefln) calls, which introspects the printee, and prints it.
