Closed jbgi closed 9 years ago
There are many bike shedding opportunities...
I've always wanted to make toString method reflective. The result should be that I can copy text produced by toString method right into java source code. I've considered
The problem with this format is that I'm not sure that constructor-methods will always be like this. However toString is used primarily for debugging and it is common sense that users should not rely on toString format. So may be in the end toString shouldn't be reflexive not to promote reliance on the format...
What are your use cases?
My use case is for logging/debugging. I also think that users should not rely on toString format. While a reflective format could be nice, it works only if all arguments' classes also implements a reflective toString, which is an overly ambitious goal in the general case. Also I would prefer having fields names appear in the resulting string, as it helps distinguish data (especially for fields of same type). So in summary, I would prefer adt4j to use the guava conventions for toString (ie Objects.toStringHelper), for better integration with my other classes.
I've added toString implementation. Can you review recent canges before release?
Should I close this?
Yep, thanks.
given visitor interface: interface ListVisitor<T, S, R> { R cons(T head, S tail); R nil();}
I would like List.toString() to return:
...and capitalization of first letter could be a good idea (maybe?)