On Mon, 08 Mar 2010 15:56:14 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Steven Schveighoffer wrote:
On Mon, 08 Mar 2010 14:49:33 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
bearophile wrote:
Andrei Alexandrescu:
Sorry, this stays.
Then I'm not going to use the Phobos printing in all my future D2
programs. As I was not using it in D1. I'm not going to change idea
on this.
(e.g. the comma may be a decimal point in some languages, so is
[1,2] in a German locale an array of double with one value or two?<
In German you need no space after the comma, and there's no [] after
and before it. So [1, 2] is not a floating point value in German.
Why one space?<
Because that's they way people print things in natural languages.
It's a convention, you know. And it's a good one. It tells apart the
FP numbers and it's the minimal.
It's the most neutral thing I could think of. Why no brackets?
Because of minimalism. You can very easy add them if you want
them.<
The purpose of things like the square brackets is to give a less
ambiguous textual representation of the most common data structures
(array and strings are the most common after numbers). So you put ""
or '' around strings and [] to know what you are printing.
Your choice of leading/trailing symbols and of separators makes 'to'
friendlier for printing e.g. debug strings. My choice makes it a
primitive for text serialization. I'm not 100% sure which is the more
frequent use and therefore which is the most appropriate as a default,
but I'm leaning towards the latter.
No it doesn't.
Tell me how you would parse the following text serialization string
for a string[]:
hello world how are you
What if it was a string[][]?
Compare that to:
[hello world, [how are, you]]
That is almost completely unambiguous (you still have to account for
literal commas or brackets), whereas you have a multitude of choices
with the first version.
I said a primitive for serialization, not a serialization
infrastructure. So the basic idea is that you use "to" in conjunctions
with your own routines to serialize things. "to" imposes no policy.
Using "[", ", ", and "]" is policy.
Reading the documentation, it appears that setting the policy means simply
passing delimiters to the "to" function. That means that for every call
to "to", you specify the policy if it differs from the default. Since the
default is not useful for serialization and confusing for printing, why
would anyone use the default policy (aside from the obvious "because it's
annoying")? If you don't use the default policy, why have a default, why
not require the policy for each call?
The thing is, friendlier for text-based serialization is almost
identical to friendlier for printing. In fact, friendlier for
text-based serialization should have even more annotations to escape
delimiters.
In fact, I find the defaults you defined not useful in most cases.
Printing or serializing, I want to see the delimiters for the arrays,
elements, and subarrays.
You can choose them no problem. std.conv gives you mechanism, you choose
the policy.
I can choose the policy for each call, that is not going to look very
good, and be very tedious to write. Plus it's not recursive (this would
actually be a huge problem if using to for serialization):
import std.stdio;
import std.conv;
void main()
{
int[][] x = new int[][](2, 2);
writeln(to!string(x, "[", ",", "]"));
}
outputs [0 0,0 0]
I would expect [[0,0],[0,0]]
I'll also point out that AAs have a default policy that is much more
reasonable.
-Steve
