Re: A small proposal: Not Sorting in AnalyzeSerializablesJUnitTest
I categorically like style improvement and enforcement. +1 to this specific style improvement and enforcement. It's pretty straight-forward to write a regex into our spotless.gradle. Let me know if you need a hand on that front, since I know I shouldn't use "straightforward" to refer to either of regex or gradle. On Mon, Nov 12, 2018 at 5:28 PM, Galen O'Sullivan wrote: > Hi all, > > I wrote a PR (GEODE-5800) recently to remove redundant cases from > DataSerializer.readObject etc. calls. This changed the bytecode size (but > not the behavior) of a number of DataSerializables, and I realized that the > task of updating the list (or viewing the diff) was made harder by the fact > that our sanctionedDataSerializables list has gotten out of order. I would > like to propose forcing the list (and probably sanctionedSerializables as > well) to be ordered and the files to be equal, as I see no benefit to > having the files out of order, and I do see a benefit to having > configuration files like this rigidly defined so that we can analyze and > read diffs better. > > Thoughts? > > Thanks, > Galen >
Re: A small proposal: Not Sorting in AnalyzeSerializablesJUnitTest
If it makes easy to find/address failure with AnalyzeSerializablesTest, +1 -Anil. On Tue, Nov 13, 2018 at 9:34 AM Kirk Lund wrote: > +1 I've had to reorder the list a few times myself to correct the ordering > > On Mon, Nov 12, 2018 at 5:28 PM, Galen O'Sullivan > wrote: > > > Hi all, > > > > I wrote a PR (GEODE-5800) recently to remove redundant cases from > > DataSerializer.readObject etc. calls. This changed the bytecode size (but > > not the behavior) of a number of DataSerializables, and I realized that > the > > task of updating the list (or viewing the diff) was made harder by the > fact > > that our sanctionedDataSerializables list has gotten out of order. I > would > > like to propose forcing the list (and probably sanctionedSerializables as > > well) to be ordered and the files to be equal, as I see no benefit to > > having the files out of order, and I do see a benefit to having > > configuration files like this rigidly defined so that we can analyze and > > read diffs better. > > > > Thoughts? > > > > Thanks, > > Galen > > >
Re: A small proposal: Not Sorting in AnalyzeSerializablesJUnitTest
+1 I've had to reorder the list a few times myself to correct the ordering On Mon, Nov 12, 2018 at 5:28 PM, Galen O'Sullivan wrote: > Hi all, > > I wrote a PR (GEODE-5800) recently to remove redundant cases from > DataSerializer.readObject etc. calls. This changed the bytecode size (but > not the behavior) of a number of DataSerializables, and I realized that the > task of updating the list (or viewing the diff) was made harder by the fact > that our sanctionedDataSerializables list has gotten out of order. I would > like to propose forcing the list (and probably sanctionedSerializables as > well) to be ordered and the files to be equal, as I see no benefit to > having the files out of order, and I do see a benefit to having > configuration files like this rigidly defined so that we can analyze and > read diffs better. > > Thoughts? > > Thanks, > Galen >
A small proposal: Not Sorting in AnalyzeSerializablesJUnitTest
Hi all, I wrote a PR (GEODE-5800) recently to remove redundant cases from DataSerializer.readObject etc. calls. This changed the bytecode size (but not the behavior) of a number of DataSerializables, and I realized that the task of updating the list (or viewing the diff) was made harder by the fact that our sanctionedDataSerializables list has gotten out of order. I would like to propose forcing the list (and probably sanctionedSerializables as well) to be ordered and the files to be equal, as I see no benefit to having the files out of order, and I do see a benefit to having configuration files like this rigidly defined so that we can analyze and read diffs better. Thoughts? Thanks, Galen