burtonator wrote:
> -----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... :(
I don't see the problem here.
>
>
>>> 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.
Because someone either can't or won't update the generator. I am a HUGE
fan of generators, as long as you understand what is generated and how.
>
>
>> 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>
>
I have written something close to what Torque does over in Turbine land,
except that it generates SQL schema, Java objects, and the webapp to
access said objects. I can tell you that it *is* complicated, but it is
maintainable. The minute I catch myself editing the output, I ask
myself 'Why?', and then modify the generator. The only valid use case
for modifying the generated code is to test something before you put it
back into the generator.
>>> 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.
>
Modify the generator. If you created it, and you have the source, you
can modify it, no?
>
>>> 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.
How many APIs do you use that you didn't create? Do all of the follow
your conventions? I would doubt it.
>
>>> 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>
>
There is generally a lot more context than just 'something'. Generated
JavaDoc can be just fine as opposed to no JavaDoc.
> 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.
The only thing that I see here is that Jeff has the itch, and I say let
him scratch. If he ends up with something better, faster, more
extensible, so be it. If not, he gets the education for trying. It is
as simple as that.
Scott Sanders
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
