On Sat, 2 Nov 2013 17:35:17 +0000, Sean Owen wrote:
On Sat, Nov 2, 2013 at 4:49 PM, Phil Steitz <phil.ste...@gmail.com>
wrote:
If the improvements make a material difference [1], by all means
open tickets and submit patches. If they are just cosmetic, my
personal opinion is this should be done in small commits
incrementally if at all [2]. It is OK to open master tickets to
track style / optimization changes and do the work to review and
commit them incrementally. The master ticket should be preceded by
discussion here to make sure we are all in agreement that the
changes are appropriate.
You mention quite a few different kinds of thing above. It is
probably best to break up into different discussion threads by
topical area and then open master tickets for the ones we agree to
fix / standardize. Regarding the javadoc errors (broken javadoc
references, missing / incorrect @deprecates), there is no need for
discussion - just open tickets and we can commit the fixes.
I agree with that. I'm going to file two JIRAs and probably leave it
for now. No point in getting into minutiae.
Let me turn it around: are there general clean-up tasks that people
have wanted to do for a while but not gotten to? Maybe I could take a
request or two and run with them.
One issue[1] is the unnecessarily high number of error patterns
(defined
the "org.apache.commons.math3.exception.util.LocalizedFormats" class).
If one agrees that is is not necessary that every "throw" statement
must have its own pattern, it is possible to reduce the enormous
redundancy that exists in that list of patterns.
I had proposed that error messages be incrementally built from simple
"base" patterns, to be assembled either at the point where the
exception
is going to be thrown or inside specific exceptions[2] (or a
combination
of both).
Thus, the error message will be explicitly tied to a specific code
context, where we know all the information about the error and can add
it to the message that will be carried up the calling stack.
Best regards,
Gilles
[1] Whether it is trivial or minutiae or a possible improvement, is
again
a matter of taste.
[2] If a similar error condition occurs at different places in the
code.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org