git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [1/2] ant git commit: Deprecate CollectionUtils and Enumerations; reduce explicit use of Enumeration


On Fri, May 18, 2018 at 10:07 AM, Gintautas Grigelionis
<g.grigelionis@xxxxxxxxx> wrote:
> I accepted the original criticism that going Enumeration -> List -> Stream
> has an overhead and I tried to address that by using a decorator.
> I believe that Streams API can at least implement the logic run by an
> original Enumeration in a more concise way, or provide more powerful idioms.
> That IMO makes it worth the while to investigate the Streams alternatives.
>
> In the process I also found out that other iterators could be used in a
> more efficient way, or that there is a redundant object construction going
> on.
> If you wish, I may spend some time to describe the changes I introduced,
> and maybe then we could discuss the their merits.
>
> Gintas

As a lurker on this list, but also Java developer in $dayjob [1], I'd
like to add my 2 cents, FWIW.

I see two things going on that are causing a lot of irritation / frustration:

1) Large codebase-wide changes for adapting old (well working) code to
new API's, syntax, idioms, ... usually mostly cosmetic. From my
personal perspective (I know, I carry little weight here, I'm just an
innocent bystander) this is not a good idea. Except in specific cases
for example for security reasons, or where there is a clear benefit
also for users (for example it improves performance significantly in
certain scenarios -- Note that I say "significantly", because shaving
off 1 byte off an operation that's only run once by normal users is
not worth the code churn / review effort / risk (yes that means you
need to measure and show the significant improvement if you want to
use this as an argument)).

I remember years ago we had a similar discussion at $dayjob, when
someone proposed to standardize our rules for grouping import
statements. "Should we now bulk-change our entire codebase?" After
discussion the consensus was "no" (needless code churn, review burden,
possible future backport conflicts, ...), except when you're going to
edit the class anyway. So the simple rule was: "use the new style in
new code, and in code that you're going to change for 'external
reasons' anyway".


Which brings me to the more important problem:

2) There is clearly no consensus here on the merits / desirability of
these bulk changes. Gintas, I understand your desire to move things
along, and you clearly have an opinion about it, but IMHO you really
need to stop doing any more bulk changes as long as there is no
consensus.

Several people have voiced objections on this lists ([2], [3], [4],
...), so why are you continuing to do this? When people start raising
flags you really should pause for a moment, and start discussing
before making more commits. By making further disputable commits you
are making the discussion more difficult (it's much more difficult to
freely speak your mind if the code has already been changed ... the
work has already been done and it's even more work to revert it, ...).


[1] Full disclosure: I work at the same company as Maarten Coene. I'm
also an ASF member and PMC member of the Subversion project, but that
doesn't really matter here.

[2] https://mail-archives.apache.org/mod_mbox/ant-dev/201804.mbox/%3C5682399f-c52e-49bd-a48b-740feaf60653%40apache.org%3E
and its entire thread
[3] https://mail-archives.apache.org/mod_mbox/ant-dev/201804.mbox/%3C001301d3e070%246555ff10%243001fd30%24%40de%3E
and previous answers by other committers in that same thread.
[4] https://mail-archives.apache.org/mod_mbox/ant-dev/201805.mbox/%3C87efitnm5f.fsf_-_%40v45346.1blu.de%3E

-- 
Johan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxx