Change multiset's toString

[GoogleCodeExporter]

Currently a multiset's toString returns something like "[Test x 2]". I saw
this and was like "huh, I never wrote that element: where does it come
from?" I later realized this means "present twice in the collection".

To be honest, I don't like the use of the character 'x'. In IT, the common
way to tell something is present several times is the star ('*'), not the
'x'. Or if we want to be mathematically correct, the multiply character is
better ('×'). One downside of the latter is that is is not ascii, and might
lead to unreadable characters in logs or whatever. One last possibility I
see is, as in java.util.AbstractCollection's subclasses, "Test, Test".

Additionally, the behavior of Multiset's toString is not consistent with
the behavior of Multimap's toString, which clearly states "{Test=[Test,Test]}".

[Code]
System.out.println(ImmutableMultiset.of("Test", "Test"));
System.out.println(ImmutableMultimap.of("Test", "Test", "Test", "Test"));

[Result]
[Test x 2]
{Test=[Test, Test]}

So, is it possible to change the behavior of the Multiset to one of the
above, with a clear preference to AbstractCollection's behavior?

Original issue reported on code.google.com by ogregoire on 27 Sep 2009 at 1:09

[GoogleCodeExporter]

I can think of several multisets used in Google code which would suffer an
OutOfMemoryError if they had AbstractCollection's toString() behavior!

I definitely like your suggestion of '×', but unfortunately, we've found that 
even in
this day and age, the use of non-ASCII characters in code is still causing us a 
lot
of headaches. I had a painful fallout from using an infinity symbol just in 
*javadoc*
recently, let alone the code.  It sucks that this is still the state of things 
in
2009, but it is, even in Google where we have made several attempts to get all 
the
tools uniformly using utf-8.

As for '*', I have never seen it used this way, and I personally like the 'x' 
better.

Finally, an ImmutableMultiset and an ImmutableListMultimap are two very 
different
kinds of collections, and it is only right and proper that their toString() 
outputs
should not at all resemble one another!

Thanks for the suggestion and our ears are still open.

Original comment by kevin...@gmail.com on 27 Sep 2009 at 4:06

• Changed state: WontFix

[GoogleCodeExporter]

I've just thought about another possibility: putting the occurence number 
between 
parenthesises (preceded by a space). For instance: [Test (2), Test2 (4), 
UniqueTest].

Personaly I find it more readable than the 'x'. But of course, it means one 
more 
call to the append, but in terms of length, it is exactly the same (since 'x' + 
' ' 
+ number = '(' + number + ')' ). It looks more like a "game inventory", but 
there is 
no more confusion about the 'x').

Original comment by ogregoire on 28 Sep 2009 at 2:35

[GoogleCodeExporter]

I like that idea! I also find the x to be confusing...

Original comment by yrfselrahc@gmail.com on 28 Sep 2009 at 2:38

[GoogleCodeExporter]

The parentheses idea isn't bad, so we discussed it internally, but we decided 
to stick 
with the current format.  For one thing, the parens are more likely to appear 
in the 
toString() form of the key than an ending 'x 5' is, so this could potentially 
cause 
more confusion than it eases. Thanks for the ideas, everyone.

Original comment by kevin...@gmail.com on 28 Sep 2009 at 8:07

[GoogleCodeExporter]

Okay.

I'm sure of a no again, but anyway this time I propose the following syntaxes:

1. [1x(Test), 2x(Test2), 3x(Test3)]
2. [Test, 2x(Test2), 3x(Test3)]
3. [(Test)x1, (Test2)x2, (Test3)x3]
4. [Test, (Test2)x2, (Test3)x3]

Examples with parenthesis:
[1x(()Test(), 2x()Test), 3x(Test)Test(Test)]

All of these are readable and still use the "xN" syntax that is less likely to 
be
encountered as you rightly point out.

Original comment by ogregoire on 28 Sep 2009 at 8:23