On Mon, Jul 20, 2009 at 4:23 PM, Jason Weinstein <jasonweinst...@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
