|
Code generation versus reflection
The recent book by Jack Herrington, Code Generation in Action, (http://www.manning.com/herrington), does not even mention the word Reflection. As I can understand, is reflection superior to code generation. If the code is so predictable that it can be generated, it must be better not to generate at all. The problem with code generators is that the code must very often be manually changed, and then you have the problem of making the changes survive the next code generation. The approach taken by NakedObjects (http://www.nakedobjects.org), seems to be a better way to do it. Define the business layer and use reflection to display the GUI and also handle the underlaying database.
Christer Nilsson
Friday, January 2, 2004
"The problem with code generators is that the code must very often be manually changed, and then you have the problem of making the changes survive the next code generation."
This is mainly an issue of code generators that only work one-way. If the code generator is designed to both generate code and sync it's model with your manual changes, then you don't have that problem anymore. Together Control Center does this. You build your UML model and it generates code, but it also syncs the model to reflect manual changes made to the code.
Matt Latourette
Friday, January 2, 2004
Additionally, if you're changing the code generated by a system then either that system is broken or you have different goals than it does. The Pragmatic Programmer distinguishes between passive systems which do lots of initial typing for you (like a VC++ wizard) versus active systems, which are self-contained and should never be directly modified. When creating a code generation system one of your primary goals must be ease of customization. Whether this means you subclass or superclass (is that a word?) the generated classes with your changes is your choice, t both work very well, particularly if you're getting the objects from factories.
The standard complaint against reflection-based systems is that they're slow, but at least in Java that's being minimized with successive versions of the JDK. My main complaint is that reflection-based systems are difficult to debug, particularly for the folks who didn't write the system.
Finally, one benefit of code generation is that you can use languages more appropriate to the task (or skillset) to do the work. Most of my Java that's generated is produced from a system written in Perl. (I think Jack uses Ruby extensively in his book.) YMMV...
Chris Winters
Friday, January 2, 2004
The question of reflection vs. code generation is the same as any other sort of question about dynamic vs. static or run time vs. compile time. Doing things statically tends to be much more efficient and offers an early opportunity to catch flaws. On the other hand, doing things dynamically tends to be much more flexible and has greater turnaround time for changes (since you avoid having to recompile or regenerate code).
In .NET, there’s a convenient DataBinder.Eval function that uses reflection to bind to a field in a data container at runtime. For example, DataBinder.Eval(obj, “Name”) will successfully return the value of the “Name” field whether obj is a stream of results from a database (SqlDataReader), or an in-memory cache of data results (DataRowView, I think), or a class with a Name property, or a struct with a Name field. This is very convenient because it allows you to switch between drastically different approaches to data access in early development when you might not be sure what is best for your project yet. After seeing performance warnings a few times, I eventually got around to benchmarking DataBinder.Eval versus direct access and found a 30% performance hit on a page that only used it minimally. Is the little bit of extra convenience really worth a 30% performance hit (likely greater for more extensive use)? During early development, a 30% performance hit is usually no big deal and the flexibility increases productivity but it’s probably not something you want when the project goes to production.
When reflection (or metadata of any sort) is available to me, I do like to use it. However, I also like to make sure I have an easy way to switch over to a less costly method (code generation or hard-coding or whatever) if and when that’s necessary. I’ve found using reflection/metadata to generate code is a best-of-both-worlds technique -- for example, accessing database metadata to generate wrappers for stored procedures that are output in some compiled or compliable format.
SomeBody
Friday, January 2, 2004
Reflection and code generation are two different things. Reflection walks the specifics of a type you already have. Code generation (done with CodeDOM in .NET) generates new classes.
Brad Wilson (dotnetguy.techieswithcats.com)
Friday, January 2, 2004
I think we all know the difference between code generation and reflection. The point is that often they both can be used to accomplish a given task.
SomeBody
Friday, January 2, 2004
There are two kinds of code generation. You can use your language of choice to generate code in other languages; for example, Java can generate HTML or SQL. I do that kind of stuff all the time.
Or, you can use code generation to create code in your language of choice, such as Java. I avoid that approach, except when I use someone else's code generator when compiling CORBA IDLs.
Writing an interpreter just seems a lot more straightforward. Instead of, for example, writing code that converts an XML configuration file into Java, I'll write code that reads the XML file and follows the appropriate logic. You can avoid a significant performance cost by doing as much processing as possible during initialization.
Julian
Friday, January 2, 2004
Reflection is inspection of the properties of types.
Code generation is simply writing code based on other code. The two are not orthogonal.
Relection is often used during the code generation process. If your platform supports reflection, often code generation can be made a lot easier than it otherwise would be.
Rick Watson
Saturday, January 3, 2004
Code generation tends to be more explicit, and hence easier to debug and maintain, than reflection.
I'd also suggest categories of code generation:
* In one-time code generation, the initial code is generated, but thereafter it is maintained like ordinary code. The one-time code generator might be a script, or something like an editor plugin (eg to generate sets and gets).
* In long-term code generation, the generated code is never modified by hand. However, the code might be regenerated as the generator evolves.
Reflection is generally more useful in on-the-fly situations (although even there you can code generate: consider JSP as an example).
Portabella
Saturday, January 3, 2004
I have found a reflection-based example that is gaining a lot of momentum. It takes care of the data layer. See http://www.hibernate.org
Christer Nilsson
Sunday, January 4, 2004
Indeed, one of the biggest problems with code generators is when you have to manually edit the generated code, and have a need to regenerate the code after the manual editing has been done.
However, if the nature of the code is such that it needs manual editing, it almost certainly won't be suitable for runtime reflection either.
T. Norman
Sunday, January 4, 2004
Roundtrip code generation (code->something->code, e.g. with something=UML) isn't as useful as it sounds, at least not for C/C++ if you put the preprocessor to good use.
Ori Berger
Sunday, January 4, 2004
It's also worth mentioning that Aspect-Oriented Programming covers some of the same ground... another tool for the toolbox!
Portabella
Monday, January 5, 2004
I found an article covering this subject by Martin Fowler:
http://www.javaworld.com/javaworld/jw-11-2001/jw-1102-codegen.html?
Christer Nilsson
Thursday, January 8, 2004
 Recent Topics
Fog Creek Home
| 
