Court of Lord Zoltan v2

Following on from a taster that I posted before: http://lordzoltan.blogspot.com/2010/09/pseudo-template-meta-programming-in-c.html , here goes with the next piece. Firstly, the design I'm showing here can be applied to any reflection scenario - I've deployed it in various guises, including for storing meta-data about methods in a class, properties, and even for compiling dynamic methods that provide late-bound functions.  The primary reason why this design, I feel, is particularly useful is that you're making the .Net type engine do all the hard work of storing all this meta-data for you. I'll go through this by looking at a really simple scenario: You want to write a system whereby you can reflect properties of a type that a developer writes in order to provide some form of functionality.  Let us say that you want to write a dictionary state-bag wrapper, where a property is wrapped around an internal dictionary of values.  What you want is to have a code-generation

Not full details here, but I'm writing this post as part-memo to myself, but also in the hope that one or two of you might make a mental bookmark to keep checking back. In the course of my most recent project, which involve classes which wrap a common data storage mechanism (a bit like DataRows) I encountered a problem which was best solved with a solution called (coining a phrase) 'self-aware' properties.  Assuming all the storage access code is provided in a common base, and using attributes to define the string name of the 'column' (to continue the DataRow analogy) to which a property is mapped: class X {   [MappedProperty("actualvaluename")]   public string SomeValue   {      get      {         return base.GetPropertyValue("SomeValue");      }   } } So far so rudimentary.  However, I wanted my framework to be able to support inheritance, so that a class inheriting from another one not only could inherit it's properties, but also so it