During my development of ProS I’d had to dig into Reflection.Emit again and one thing that keeps puzzeling me is the way the class in Reflection.Emit is designed.
Take for an example Typebuilder, the corner stone of creating a new class using Reflection.Emit. It inherits from Type however most, if not all methods it inherits from Type is overriden with a version that throws an exception explaining that that particular method is not available on TypeBuilder. The same goes for MethodBuilder, PropertyBuilder and all the other builders That all inherit from xInfo.
The design decision is a hefty violation of the liskov substitution principle (LSP) and for just that reason I’d say they need a really good argument for it. It basically results in yoou having to build a framework for reflection on your newly created types and members to be able to create a compiler. It’s a trivial but time consuming process to make that reflectio possible and well since it’s trivial I can not find that really good argument for violating LSP.
Needless that Im a huge fan of designing by contract, that’s basically my driving motivation for creating ProS, and devolping ProS I hope Im not violating LSP. If I am that is going to give me even more grey hair when I get to testing the plugability. The supporting structure of the plugability is LSP.
Failing fast to learn a lot 