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
