commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <>
Subject Re: New Tag - Looking for Comments (Maintain user code during regeneration of files)
Date Tue, 21 Jul 2009 00:40:09 GMT
On Mon, Jul 20, 2009 at 4:23 PM, Jason Weinstein <
> wrote:

>  Ok so another not so good example. I was not suggesting an
> implementation for webservices. If you want to use a config file, some IOC
> technique, you're more than welcome to use a config file.

I was not suggesting use of a config file.  I was suggesting the use of
standard language facilities such as class extension.  Thrift is a
proof-by-example that this is possible in many target languages.

> .... However this [avoiding rewriting of generated code] is not always the
> case.

Inability to avoid over-writing is a show-stopper bug in my book.

>  Still back to the example at hand, given wsdl-first (contract first)
> code generation, in your case the code generator would generate
> something like...
> The config file contains things like you describe: an endpoint name, and
> which class is implementing the endpoint, etc

And here is your first chance to avoid changing generated code.  Just extend
the sample implementation and provide that extension in the config file.

> ... Lets say you hand add more entries. Next time you run code gen you will
> overwrite this file and lose your hand entries. Now what i am
> suggesting has to do with "jelly" and its use as a code generator. In
> the above case the file generated would look something like:

Don't do this.  Write your own config file.  Using the code generators
config file is asking for disaster to strike.

> Similarly you can do the same for method bodies, etc. When people make
> extensive use of code gen not just to gen the wsdl or java files but
> other framework code, it becomes important for the user to be able to
> overwrite/workaround generated code as it is not always correct and
> what the user wants.

I have heard this said before.  I have never (in nearly 25 years of using
code generation tools) seen a case where it was absolutely required.
Moreover, I have never seen a case where it did not lead to horrific
maintenance nightmares.

> Anyway using the same example as before but in this context, lets assume
> the generator generated this file
> ... java file deleted ...

This is a non-issue.  Use inheritance.

...   public int doubleIt(int numberToDouble) {
>        // [[100-usercode]]
>        //enter your code here - it will not be overwritten next time you
> codegen
>        // [[100-usercode]]
>    }
> }
> In fact what i described allows the code generator to flag files which
> have been modified by users potentially alerting them to incompatible
> changes they may have made.

This leads to a horror in terms of file dependencies because the output of
the code generator depends on the output of the code generator.

Using inheritance to over-ride the behavior breaks this dependency cycle and
avoids the problem entirely.

This is commonly referred to as Roundtripping (which is not necessarily a
> bad thing) and most code generators do not support it. I have presented a
> way to support simple roundtripping needs in code generators like "jelly".

This is a key point and I think we dramatically differ on this.

You say that round-tripping is not necessarily a bad thing and I say that it
is *necessarily* a bad thing.   As in, it is not a good thing.  Indeed, it
is a bad thing.

Ted Dunning, CTO

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message