More Native Reflection, Please!

Sometimes you wonder why you keep on producing the same kind bugs again and again...

... and you hope someone will show you how to find a remedy.

This post is left to be found by the programming language designers of today... and whoever finds it interesting.

The Problem - Example #1

PropertyInfo propertyInfo = this.GetType().GetProperty("SomePropertyName");

Above very powerful state of the art reflection fetches a PropertyInfo instance that can be used to set/get property "SomePropertyName". The Type class facilitates a number of reflection services as normal C# members in a very general and loose coupled manner e.g. you enter a string in the GetProperty-method.

The problem comes when someone renames SomePropertyName with a built-in refactoring utility of an IDE. The string argument is a weakness in above code that just waits to break the code.

The Problem - Example #2

[Reference(InitializeFromPropertyId = "EntityId")]

SomeEntity ReferenceEntity

{

get;

set;

}

Imagine that above code is part of an interface or class and it means that the class - when instantiated - will initialize a reference to another entity of type SomeEntity using property EntityId. This time we have the same problem - the string argument in the annotated Reference-attribute won't be changed if the property name is refactored.

Counter Example

Type type = typeof(Org.Foo.Bar.MyClass);

Above works like a charm with refactoring. If MyClass is renamed, the code doesn't break.

The Simple Solution

PropertyInfo propertyInfo = propertyof(Org.Foo.Bar.MyClass.SomePropertyName);

Could you guys* (continue to) make reflection part of the programming language! ... Please ... Soon?

* Anders Hejlsberg and others...

Code generation with partial & Attribute

The last couple of weeks I have built a Visual Studio Addin that can help up with trivial editor features and not so trivial features like code generation.

One of the things that I am going to try the next couple of weeks is to generate a default implementation class from an interface.

2 ways to structure basic code generation in C# are:

• the C# form approach where a class is split into 2 files (1 generated and 1 editable) with the partial keyword, and
• the "double-derived" pattern with a base and implementation file (1 generated and 1 editable)

The first mentioned approach doesn't support that you can choose what should be generated and what shouldn't; you just have to live with the split made by the generator.

The second approach adds an extra inheritance link and you avoid calling the generated code by overriding methods/properties and not calling it via base; generated code becomes dead code.

Here is a 3rd approach... and I have yet to see if it works in practice.

Generate a partial class with 2 files

First we generate "Class1.cs", the editable file, and "Class1.generated.cs", the generated file.

They could look as follows:

Now the developer wants to customize the Bar property...

Support developer customization

The developer cut-paste the Bar code to the editable file, removes the Generated attribute and performs her customizations:

What happens now when the code generator is called again to create Class1?

Re-generate the partial class generated file

The generator uses reflection on the compiled assembly and only generates missing properties/methods and re-generates the properties/methods with the Generated attribute....

This means that the developer's changes are kept intact and she actively decides on the features being generated.

Maybe it can be done that simple... the catch is that the generator only can respect successfully compiled developer changes... but that might be OK e.g. Test Driven .Net requires a successful build to run tests.

Version-ed interfaces to refine a product specification?

Warning! This is just an idea. You will have to prove its value yourself!

Interfaces as product specifications

Nothing new here.

An interface defines some behavior that can be implemented by one or more classes.

Interface methods and properties

• define inputs and outputs (interfaces as arguments and return types),
• may have annotations (attributes that means something), and
• have documentation (e.g. with references to specifications and/or examples).

Version-ed interfaces

Here comes the first idea.

Lets say that a product release of some features are to be version 1.

Here is what a (wacky) coder could have produced to materialize one of those features:

The 1st idea is to name the interface with a version number.

"Thats just insane! Why would you do that! ....."

Usually we don't change the name of the interfaces and it works fine, but lets see the next Foo specification:

This certainly is a bit strange. Apparently, now a Foo does not drink stuff from the bar, but only buys it. Definitely, strange.

This version 2 interface is renamed, specializes the previous interface by inheriting it and redefines the Bar method by using the new keyword.

Thats 3 things that you normally do not see:

• The rename: It will have no effect on existing version 1 implementation, but require your implementation to be changed when it is to support version 2.
• The specification inheritance: This is a very explicit way of tracking the specification history that might suite coders just fine.
• The redefine with new: The Bar signature did not change, but the textual specification did. If the interface was named IFoo and the text just changed between version 1 and 2, then the compiler would eat everything just fine, but the version 1 implementation would still make Foo drunk whenever he went to the bar.

Implementation changes

Here is how a version 1 implementation could look:

The version 2 could be:

A tiny difference, but a fatal one when on a date!