commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
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 <jasonweinstein@hotmail.com
> 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
DeepDyve

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