-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Daniel Rall <[EMAIL PROTECTED]> writes:
<snip>
> Of course not. Generated code should never live in CVS--only the
> generator should.
... ah. so we add another lib in CVS and then the code to drive this gets added
as an Ant task... :(
> > What if you make subtle modifications to them.
>
> Local edits to generated code should never be made for any reason
> other than testing.
No way... it happens all the time.
> Assuming the tests indicate that permanent changes are desired, the generator
> or its input(s) is then modified to produce the new output.
Nope. Doesn't work that way. Most code generators are as convoluted as
compilers. Try adding new syntax to a compiler.
<snip>
> > 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).
There can be a log of situations where you don't want it in CVS. If you need to
make any changes though, remove methods, etc you have to commit this to CVS.
> > 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.
I care. I don't want to use an API that uses a non standard pattern or a
different naming convention than what I already have. This is a Bad Thing.
> > javadoc for generated APIs is usually terrible.
>
> Huh? Sounds like a problem with the generator. Fix the generator.
All generators have problems. It is the nature of the beast. What do you
expect the generated javadoc to look like?
/**
Get Something
@return String something
*/
public String getSomething()
... not very descriptive.
<snip>
BTW. These questions were rhetorical. My point in the original e-mail was that
code generators can be "non-ideal". I wasn't making a logical argument against
them just that there was enough evidence to consider using the small parser we
already have. Considering the above issues (which don't exist currently) it IMO
isn't worth switching.
Kevin
- --
Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] )
Cell: 408-910-6145 URL: http://relativity.yi.org ICQ: 73488596
Patriotism is the last refuge of a scoundrel.
-- Samuel Johnson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
iD8DBQE65KKOAwM6xb2dfE0RAnfAAJ9E7uDLECFZzuZR6/CNbQu4KYjusACgwo2C
gi9s7dRb7i5F6VoS+RmaJDg=
=dDQT
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
