[math] project wide approach to toString() methods

[Tim O'Brien <to...@discursive.com>]

toString() methods are possibly the most trivial thing in the world, but,
for consistency, it might make sense to embrace the Commons Lang
ToStringBuilder everywhere we need to implement toString().  *I'm not
advocating the use of the reflection builder*, but we have a number of
places where a toString() method is implemented by creating a StringBuffer
or just concatenating strings ourselves.

Another topic is how some of the classes have a toString() method which
contains considerable "logic", like how to print a Matrix or a Frequency.  I
think it would be a better decision to create "Printer" objects which allow
you to configure how something is output.  This is similar to the way that
Map doesn't hold any formatting information, instead we have debugPrint()
and verbosePrint() on MapUtils.  (But, I don't advocate an explosion of
XXXUtils objects in Commons Math)

Note that this does not apply to o/a/c/m/function/simple package.  That
would just be silliness as the toString() is simply returning one string.
(Although someone is free to suggest that we externalize all strings in the
system for internationalization, I think this is a good idea generally for
J-C.)

Here's a list of issues:

0. SummaryStatisticsImpl  - this one would be simple to use ToStringBuilder
with.  (If we've got Commons Lang, let us take advantage of it... )

1. AbstractDescriptiveStatistics - this one would be simple to use
ToStringBuilder with.

2. Frequency - This one is tricky, and I'm wondering if this is really an
appropriate use of toString().  Frequency's toString() prints out a tab
delimited table which lists the frequency of each element.  I think
something like this may make more sense as a FrequencyFormat object.
Anyone?

3. RealMatrixImpl - Again, I think we should have a MatrixFormat that takes
care of printing a matrix.  Or a MatrixPrinter, I'm definitely not stuck on
the idea of extending java.text.Format.

Just for added emphasis, if someone decides to do any of this this, don't
use a reflection builder, that wouldn't work for clients with restrictive
security policies.


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org