burtonator <[EMAIL PROTECTED]> writes:
> Daniel Rall <[EMAIL PROTECTED]> writes:
>
> > [EMAIL PROTECTED] (Kevin A. Burton) writes:
> >
> > > I also don't like generated APIs. This is
> > > one of the main reasons not to use something like Castor/Antlr.
> >
> > Bah. Generated APIs just need proper encapsulation (shocking that the
> > rest of the program works like that too, eh?). Use of a parser
> > generator is a very good suggestion.
> <snip>
>
> ... it can get pretty dirty.
So can my shower, if uncleaned for months on end. ;P
> do you put the APIs in CVS?
Of course not. Generated code should never live in CVS--only the
generator should.
> What if you make subtle modifications to them.
Local edits to generated code should never be made for any reason
other than testing. Assuming the tests indicate that permanent
changes are desired, the generator or its input(s) is then modified to
produce the new output.
> if you don't put them in CVS you have to generate them at build time.
Right. In every build system that I've used that makes use of
generated code, this has been made trivial (autoconf, automake,
Torque, etc.).
> if you put them in CVS then every time you change the API generator you get
> redundant CVS commit messages
Putting generated code in CVS is never anything more than a stop gap
measure. The only time that I have ever done this was before the
generator was integrated into the build system (as soon as that was
done, bye bye generated code).
> generated APIs don't follow your coding conventions.
Who cares. You never manually edit them anyways. All a consumer is
interested in is the interface, not the code itself. If otherwise,
bigger problems are afoot.
> javadoc for generated APIs is usually terrible.
Huh? Sounds like a problem with the generator. Fix the generator.
> I think the solution to some of these is to expose your generation via XSLT. My
> xjay (http://xjay.sourceforge.net) project solve some of these but I didn't have
> a chance to take it too far.
I fail to see the distinction between XJay and what I understand you
to be arguing *against*. Perhaps you'd care to elaborate (feel free
to take this to private mail if you don't consider this to be the
right forum for discussing this).
Daniel Rall
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
