What should I do w/ the metadata?

Imagine I've got some "metadata" that describes some functionality of my system, e.g. the command line parameters to a tool:

<args description="Two wrongs don't make a right, but three lefts do">
  <arg name="lefts" description="Number of left turns" type="int" default=4" />
  <arg name="attitude" description="Driver attitude" required="true" type="string" />
</args>

Once I have this "metadata" in place, should I a) use it to generate a class at compile-time that implements the command line parsing, or should I b) use it to drive a command-line parsing framework at run-time?

If I do a), generate the code, the result might look like this:

class Args {
  public void Parse(string[] args) {...}
  public string Usage { get {...} }
  public int Lefts { get {...} set {...} }
  public string Attitude { get {...} set {...} }
}

I've got better perf, but I have to generate the code in some way and .NET doesn't come with any built-in tools to do that (no, I don't count ASP.NET or XSLT as good codegen tools). Plus, the command-line args are now baked in and require a re-compile to change and who cares about perf to parse the command line? Finally, I'm much more likely to have most of the work done in a base class, e.g.

class Args : ArgsBase {
  public void Parse(string[] args) { return base.Parse(args, ...); }
  public string Usage { get {...} }
  public int Lefts { get {...} set {...} }
  public string Attitude { get {...} set {...} }
}

In my experience, most of the work of code-gen is generating the smallest possible bit of code to provide a nice wrapper around a base class that does most of the work in a very interpretive manner.

If I do b), have a run-time interpretter of the "metadata," I've got to build a command-line argument interpreter, but, as I've said, you almost always have that anyway. However, I also give up a develop-time wrapper aka "Intellicrack" which will be pried from my cold, dead fingers.

What do you guys do?

Here at Corillian, we use XSD to describe messages and WSDL to describe interfaces, then use CodeSmith to generate strongly-typed classes from the schema. A NAnt build script drives the codegen-compile process, which is kicked off by CruiseControl whenever code is checked into the source repository. Easy!

I think you hit the nail on the head with your hybrid solution. That's certainly what we propose in the Software Factories space. i.e. you have a framework (your interpretive bit) and you generate code from your model (or metadata) to complete that framework in a way that's specific to your domain.

Actually a nice example of a miniature factory. I seem to remember you asking for one of those once ;-)

You wrote that .NET does not come with any good tools to do code gen. Sometimes, you can get a long way in a short time by rolling your own - just writing your own C# code to spit out the (generated) C# that you require. That approach as worked well for me.

Yup, use CodeSmith. I used CodeSmith for everything, because it's just so easy and efficient to code gen something with it. If you provide an XSD for your XML, then it's even easier. Check it out!

I've developed a similar hybrid approach for a customer; we have a base class that handles the basic parsing, and a set of thin wrappers that provide intellicrack for specific instances. We gen the wrappers at design time, using CodeDom. If the instances ("config files", in your example) change, everything still works at run time; we just don't have strong typed intellicrack until we re-run the design time codegen tool.

just like xsd.exe...

Is this what you mean by 'runtime interpreter'?

The base class should use reflection on itself to discover all of it's properties (which the derived type will create), and then set them from the metadata. Similar to how XAML works.

Hell, I'd just use xaml and be done with it.

PS In the generate-your-own approach, it's much easier to use ICodeCompiler.CompileAssemblyFromSource() (compared to than the other parts of CodeDom). You can just generate C# code as strings.

More here: http://steve.emxsoftware.com/ReflectionEmit+vs+SystemCodeDOM
and here: http://www.agilekiwi.com/on_the_fly.htm

I made this blog post about how an ML programmer would do it:
http://strangelights.com/blog/archive/2005/08/13/1210.aspx

It even contains an implemetation in F# and C#.

My theory is to err on the side of compile time:

1. Compiler "sponsored" syntax checking
2. Strong-typing

One reason I don't like interpreters and engines is that if they get too complex, they're hard to understand for the maintenance programmers.

The advantage of codegen is that the result code is plainly viewable during debugging and you know exactly what's going on.

bcfmwp gnwjzm ijaysog fjuvcsz maigzk stfei ibcmuxr http://www.qbgkfejy.rcodqt.com

actvi jnlcy ygivek sckrdqpw jalhivrpm jrmp sdujhnb [URL=http://www.veig.elwvtfc.com]sgyaqlknc tfjuks[/URL]