Discussion | Language Integrated Deterministic Reflection

[DuckScapePhilip]

Reflective programming is a very powerful tool that unfortunately will never out-perform direct calling in the code. I suggest that we extend C# to allow for fast deterministic reflection that is native to the language and is as fast as direct calling in the code. This will allow users to write code that can be extended more easily and less error-prone than manually writing out the code. I have proposed a solution below that I'm sure is not 100% polished, but I think it's a good start for what a feature in C# might look like.

LIDR

(Pronounced “Lie-der”)
Language Integrated Deterministic Reflection
White Paper
By: Philip L. Heggelund

Synopsis

Reflective programming is a very powerful tool that unfortunately will never out-perform direct calling in the code. I suggest that we extend C# to allow for fast deterministic reflection that is native to the language and is as fast as direct calling in the code. This will allow users to write code that can be extended more easily and less error-prone than manually writing out the code.

Deterministic Vs. Non-Deterministic Reflection

In my experience, I have found you can classify the user reflection in 2 different ways, Deterministic and Non-Deterministic. There is Deterministic Reflection where the code written in reflection could be manually written because all actions that the reflection is taking can be determined before the code is executed. Whereas Non-Deterministic reflection is the opposite and you may not know the exact action the user wishes to take.

An example of Deterministic Reflection would be a reflective copy constructor on 2 non-dynamic classes.

An example of Non-Deterministic Reflection would be reflectively calling a method on a REST interface inside a REST Service using the command provided by the HTTP Request.

LIDR Property Expressions

A property expression is an expression applied to each property in a class. These expressions are pre-compiled into C# code that can be previewed. During debug, the code is translated into its pre-compiled C# code and the user can step through the code generated by the LIDR.
Shallow Copy Constructor
Let’s say that we have the following class:

public class SomeClass
{
	public long ID { get; set; }
	public string Name { get; set; }
	public TRXML XML { get; set; }
	public byte[] SpecialAttribute { get; set; }
}

Now let’s say we wanted to write a copy constructor for this class. Using LIDR, here is an example of a shallow copy constructor.

lidr properties (property)  => {
      this.{property.name} = other.{property.name};
};

This would translate to:

this.ID = other.ID;
this.Name = other.Name;
this.XML = other.XML;
this.SpecialAttribute = other.SpecialAttribute;

Specialized XML Serializer

Here is an example where you could filter to only attributes decorated with [DataMember] and then also do different things depending on the type of the property. Here we are going to do a deep copy of the XML attributes.

lidr properties
(typeof(DataMemberAttribute))
(property)  => {	
	case (property.Name == “SpecialAttribute”): LIDR.DoNothing;
	case (property.Type == typeof(TRXML)): this.{property.Name} = TRMXL.CreateFromString(uom.{property.Name});
	default: this.{property.Name} = uom.{property.Name};
};

This will pre-compile into the following:

this.ID = other.ID;
this.Name = other.Name;
this.XML = TRXML.CreateFromString(other.XML);

Property Expression Handlers

In order to speed up the writing of LIDR Property Expressions, we will introduce Property Expression Handlers. These are generic handlers than can be used to compute a LIDR Property Expression and can be re-used on multiple LIDR property expressions.
These will be implemented like the following:

public class XmlSerializerPropertyExpressionHandler : ILIDRPropertyExpressionHandler
{
	public bool FilterProperty(LIDRProperty property)
	{
		return (property.Attributes.Exists(a => a.AttributeType == typeof(DataMemberAttribute)));
	}

	public lidr properties OnHandleExpression(LIDRObject other)
	{
		case (property.Name == “SpecialAttribute”): LIDR.DoNothing;
		case (property.Type == typeof(TRXML)): this.{property.Name} = TRMXL.CreateFromString(uom.{property.Name});
		default: this.{property.Name} = uom.{property.Name};
	}
}

And can be used like so:

lidr properties ShallowCopyPropertyExpressionHandler(other);

Strong Typing, Compiler Warnings, and Debugging

When displaying compiler warnings and IntelliSense errors, the compiler will display the warnings the user would see as if they had manually written out the code themselves. This will enforce Reflection with strong-typing and allow the user to see any compiler warnings that might arise from the code as if they had manually written it.
When debugging the user will see the output of the LIDR statements and not the LIDR statements themselves. They can step through each line of code that was generated.

| This is very similar to the proposed idea here: [Discussion: Static Reflection]|(#506)

[HaloFour]

Also similar to this: #2939

[DuckScapePhilip]

Thank you for that, I wanted to post this here because I feel like I had a more rounded out proposed solution than the previous submissions.

[qrli]

Build-time static code-generation with reflection can be achieved today with built-in T4 features of VisualStudio.
Combining with partial class feature, it is easy to put some functions in .tt files to be generated.

[DuckScapePhilip]

@Qril wouldn't I have to create a text template for each class I want to use this in?

[qrli]

@DuckScapePhilip No, you don't have to. A text template is simply for a .cs file, which can contain multiple classes or even multiple namespaces if you like.

[DuckScapePhilip]

@RUSshy I agree, I looked into the text templates, and although they can solve this issue, I felt like having this baked into the language would make things so much simpler.