Strawman proposal: how about we internally continue to count permutations from 0; but any time we produce a user facing message, we add 1 to make it 1-based instead?
The only real reason for suggesting this is-- I think it already works that way in 90% of the cases. So maybe we just have to decide on the remaining cases. The question regarding symbolMaps is really whether those are meant to be read by humans, or machine. If the former, then we 1-base it, if the latter, 0-base. I'm not attached to this idea. I'd be just as happy making permutations 0-based in all cases and updating the log messages to not add 1. We could also make them internally start from 1, but that's more likely to break code, including google3 code that expects symbolMaps to be 0-based. On Fri, Nov 20, 2009 at 11:13 AM, Katharina Probst <[email protected]>wrote: > Hi Lex, > > you make a good point. There are a couple of counter-arguments, however: > the logging output already uses 1-based counting, and for end users 1-based > counting is probably more intuitive. > > Are permutation IDs used in any other artifacts produced by the compiler > (other than symbol maps) that I'm not aware of? Would it make sense to > change everything publicly facing (and this, by the way, will include our > stories[permutationId].xml.gz files, etc.) to 1-based counting? > > My concern with changing everything to 1-based counting inside the compiler > is also that it will touch a lot of files. A quick look confirmed that > there are, for example, counters that count down the iterations to 0. > > kathrin > > > > On Fri, Nov 20, 2009 at 9:46 AM, Lex Spoon <[email protected]> wrote: > >> Consistency is good, but this patch breaks a different consistency! >> Specifically, the symbolMaps files count permutations from 0. So >> permutation 3 in the compile report would be permutation 2 in the >> symbolMaps files. I think that consistency is more important than >> that the permutation counting and split point counting use the same >> numbering. If someone reads about permutation 3 in their compile >> report, they should be able to safely look at permutation 3 in the >> symbol information and in any other files the compiler emits. >> >> The easier of the two numberings to change is the permutation >> numbering. The symbol maps numbering must be coming from some >> PermutationResult or something. We could trace backward to find out >> where that number originally comes from, and shift them all to be >> 1-based. >> >> Making the split point numbers 0-based is certainly possible but could >> touch a lot of code. The biggest issue is that CodeSplitter already >> uses split point 0, which doesn't really exist, as a convention >> indicating the initial download. If split point 0 was a real split >> point, then some other number would have to be used. >> >> Lex >> > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
