NaN is my vote too from a correctness standpoint. Really, Arrays.fill() is unnaturally slow to fill in NaN? this sounds odd. Is it significant?
On Tue, Dec 15, 2009 at 1:26 PM, Benson Margulies <[email protected]> wrote: > My first reaction was to be opposed to checking in generated output, > but now I can't really think of a strong objection. A separate maven > profile to enable the generator, and off we go. > > As to float and double, they may need to be special cases. Ask > yourself: "What should get(k) return when containsKey(k) is false and > the payload is double?" > > Answer 1: NaN. > Answer 2: zero, like with the int types. > > Answer 1 feels more correct, but I've discovered that the JVM is very > slow in filling an array with NaN values, whereas, of course, new > delivers a supply of fresh, clean, zeros in a jiffy. > > > On Tue, Dec 15, 2009 at 7:12 AM, Grant Ingersoll <[email protected]> wrote: >> >> On Dec 14, 2009, at 11:38 PM, Sean Owen wrote: >> >>> I think both are desirable. Check in the generator and also the >>> generated code. It just keeps it simple. >> >> +1. This is what Lucene does w/ the QueryParser (JavaCC) and the Ant script >> detects when the two are out of sync and then regenerates. >> >>> >>> On Tue, Dec 15, 2009 at 1:43 AM, Benson Margulies <[email protected]> >>> wrote: >>>> The idea here is that the templates are checked in. The build process >>>> goes template-to-java and then compiles the java. In other words, the >>>> java classes are not checked in and editable. >>>> >>>> If this is not acceptable, I'll just manually create all the classes. >>>> It's just easier to keep them in sync if there's one source instead of >>>> 16 to edit. (The presumption here is that all of 16 classes >>>> {Byte,Char,Int,Long}x{Byte,Int,Char,Long} are really identical except >>>> for the data types). >> >> >> >
