burtonator <[EMAIL PROTECTED]> writes:
> 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... :(
Yes. It works very well in practice.
> > > 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.
The only reason that I could see local edits being necessary would be
due to a lack of flexibility in the generator. Use and support of an
open source tool set makes this a non-issue. Any local edits that
happen for reasons other than testing are attributable only to a lack
of discipline in development process.
> > 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.
I see no reason to commit the output of a code generation tool to
revision control. Instead, changes can be made either to the inputs
to the tool, or to the tool itself. Since the output is just a
byproduct of the first two, there is no need to revision control it.
> > > 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.
If this is a true concern, I suggest using wrappers/adaptors that
present an API that you're more comfortable. That thin layer of code
I would check into CVS, but then you have to maintain it if any of
your generated APIs change. Personally, I have not found this to be
an issue. Rather, the patterns used by the generator become quite
obvious as I become more familiar with the code, and eventually allow
me to never have to consult the API documentation at all. IMO, a nice
trade off for the introduction of a foreign style. With generators
such as Torque, one has so much control over the output that it is
trivial to modify it to a style that one finds more suitable.
> > > 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.
Since I would in that case look at the generated JavaDoc, that is a
non-issue. :)
> 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.
I disagree. Most of your points are supported by an argument which
apparently stems from having either little control over an inflexible
generator or using less than ideal development practices (i.e. local
edits). Please don't take this as an attack, but I just don't see the
how the "evidence" applies if a more flexible generator is used in
conjunction with good practices. :)
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
