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). > > >
