On 11/2/13 8:19 AM, Sean Owen wrote: > There are tens of possible types of changes here, each affecting tens > or even 100+ files. I wondered if it would be irritating to open, > potentially, tens of JIRAs. > > Maybe I can start with a JIRA or two, each addressing one or a few > closely-related changes. If it's going well, I can propose more until > it's clear we're getting too fine-grained. > > I'll do this over time since some changes will affect the same files > or sections of code.
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. Phil [1] I know what "material difference" means is inherently subjective. For me it means either material performance improvement or significantly improved readability / approachability. I have consistently argued against too many "style rules" because they create barriers to entry for those trying to comply with them. Think about all of the examples you mention above in terms of new contributors, some of whom may be top notch applied mathematicians coming from a primarily C or other-language background. Why burden them (or us - which will include you soon enough - hehe) with the tedious work to make their code comply with every Java coding best practice we can imagine - *unless it makes a real difference to performance or readability*? [2] See "Value laziness as a virtue" and "Small, reversible steps" starting about slide 167 in http://www.betaversion.org/~stefano/papers/ac2006.2.pdf > > On Sat, Nov 2, 2013 at 3:03 PM, Gilles <gil...@harfang.homelinux.org> wrote: >> On Sat, 2 Nov 2013 14:52:34 +0000, Sean Owen wrote: >>> In Math, is there any appetite for large patches containing many >>> instances of particular micro-optimizations? Examples: >>> >>> - Replace: >>> a[i][j] = a[i][j] + foo; >>> with: >>> a[i][j] += foo; >>> … which is faster/leaner in the byte code by a little bit. It might >>> make a difference in many nested, tight loops. >>> - Inefficient toArray() calls with 0-length arg >>> - Using Map.entrySet() instead of keySet() + get()s >>> - Unnecessarily non-static private methods/classes >>> - StringBuffer vs StringBuilder >>> - etc. >>> >>> There are some non-functional but still possibly useful, simplifying >>> changes too: >>> >>> - Add @Deprecated annotations >>> - Fix broken method refs in javadoc >>> - Removing unnecessary boxing/unboxing >>> - Using foreach where possible >>> - etc. >>> >>> I could go on for a while. Most of what I might otherwise suggest is >>> style-level stuff like fixing C-style array declarations which is >>> unlikely to be useful enough to justify. Or, it would involve changing >>> signatures somewhere, which is probably not cool. >>> >>> If there’s interest in these sorts of things I can generate one or >>> more patches easily. The downside is the disruption of large patches, >>> perhaps breaking existing patches. >> >> I think that is good to have a uniform style. >> But why would a big patch be unavoidable? Reviewing a few changes is easier. >> >> Thanks for your help with this, >> Gilles >> >> >> [1] If just for better readability. But not the majority shares this view >> around here. >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
