Don wrote:
Georg Wrede wrote:
Don wrote:
Georg Wrede wrote:
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.
How about something like BigInt? Why can't you just print it out?
?? Why couldn't you?
They're not stored as strings (not Janice's anyway), but I don't
understand the question.
You can write:
int a, b;
a=10; b=20;
writefln("%d %x", a, b);
I'd like to be able to write:
BigInt a, b;
a=10; b=20;
writefln("%d %x", a, b);
and have it behave exactly the same.
Hmm. My idea was to only have writeln (and not writefln) be automated.
(For the small/debugging purpose.)
Andrei seems to be at this, but right now I don't know enough details to
say anything. It seems to be an even bigger thing than what I suggested,
and knowing he does things in a universal way, one would assume that if
a class "wants" to be printed in some way, then maybe there'll be some
provisions for it.
But, things like BigInt, that really are classes or structs that have to
be printed in a specific way, I have a hard time figuring out how to
printe them using write_f_ln.
One way would be to have the format specification (as in "%x") be
somehow passed to the toString of the struct/class. Then the class could
decide for itself how to be printed in this case.
But even this is stretching it a bit, since some more complicated
class/struct might need a more elaborate hint than just one letter. And
by that time the whole thing starts to crumble, in usability issues, at
least.
One thing we sholuld be wary of is overdesign. BigInt is ok, but by the
time we try to include a class called CompleteSimulationOfAnF1RaceCar,
we're screwed. :-) I see no way to incorporate them into writefln or
even plain writeln. Or at least, no *use*.
