Objects.toStringHelper() should accept Class and String as parameter.

[GoogleCodeExporter]

Let's say I have an interface, an abstract class and multiple sub class.

I've delegated the toString method to the abstract class and would like it to 
show by default: MyInterface{...}. For the moment, if I have internal classes 
extending the abstract one, I keep getting weird names like numbers.

I can't have the string to show whatever I would like it does with the 
toStringHelper method. I've tried using the class and a string, but both 
returns respectively "Class{...}" and "String{...}", which is not really what I 
would expect.

So please add a way to make the following happen:
Objects.toStringHelper(MyInterface.class) --> "MyInterface{...}".
Objects.toStringHelper("MyInterface") --> "MyInterface{...}".

I don't think this is really a problem, and a pair of instanceof should make it 
work, shouldn't it? Or even a few additional method with respectively Class and 
String as parameter are good idea, no?

Original issue reported on code.google.com by ogregoire on 16 Jul 2010 at 1:01

[GoogleCodeExporter]

A Class can implements multiple Interfaces, so there no way to guess which one 
is more appropriate. Moreover, the toStringHelper helps but does not fulfill 
every way of writing the toString() methods which is up to the developer.

Original comment by amer...@gmail.com on 16 Jul 2010 at 8:29

[GoogleCodeExporter]

I agree, completely. But even if a class can implement a lot of interfaces, a 
lot of classes implement only one interface, or at least only one of the 
interface is more relevant than the others (think of a class implementing List, 
Serializable and Cloneable).

I understand perfectly that, and I think the request is extremely minor. The 
default behavior would still be the getClass() call of the given object. But 
having a few improved methods allowing some bounded extras wouldn't hurt; at 
least that's what I think.

I really like the current behavior of ToStringHelper and 80% it's perfect, but 
15 other % would require this very little change and the last 5% require a full 
writing of the toString method.

In this case, I'm just in favor of giving the 15% an improved behavior.

Original comment by ogregoire on 16 Jul 2010 at 8:39

[GoogleCodeExporter]

Unless I'm missing something, adding toStringHelper(Class) does seem like a 
good idea, because some users are already passing a Class and not realizing 
that this means they're not getting what they meant.  The change is 
"incompatible" in the most infinitesimal degree I can imagine.

It should be enough to just add an instanceof check to the existing method 
without adding an overload, but it's just a little weird to specify.  But we 
might want to do it whether we added the overload or not, because it's 
considered categorically evil to have overloads that do different things on the 
same exact input instances (just depending on their types).  In which case the 
only real point of the overload would be communicating more clearly to the user 
that this is an option they have.

Original comment by kevinb@google.com on 17 Jul 2010 at 4:17

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by kevinb@google.com on 30 Jul 2010 at 3:51

• Added labels: Milestone-Release07

[GoogleCodeExporter]

Original comment by boppenh...@google.com on 2 Sep 2010 at 8:21

• Changed state: Started

[GoogleCodeExporter]

Original comment by kevinb@google.com on 8 Sep 2010 at 7:01

• Changed state: Fixed

[GoogleCodeExporter]

Thank you very much!

Original comment by ogregoire on 8 Sep 2010 at 7:19

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:15

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:09

• Added labels: Restrict-AddIssueComment-Commit