What's the System.Linq.Expressions.ExpressionVisitor.VisitExtension and the System.Linq.Expressions.ExpressionType.Extension for?

Question

The System.Linq.Expressions.ExpressionVisitor has a method named VisitExtension which seems to do nothing other than call the VisitChildren method on the Expression being visited.

protected internal virtual Expression VisitExtension(Expression node)
{
    return node.VisitChildren(this);
}

I understand what the VisitChildren does. I also understand that this virtual implementation can be and is perhaps meant to be overriden. So I gather from the documentation of the method on MSDN, which is sparing in words and briefly remarks:

Visits the children of the extension expression. This can be overridden to visit or rewrite specific extension nodes. If it is not overridden, this method will call VisitChildren, which gives the node a chance to walk its children. By default, VisitChildren will try to reduce the node.

I do not find this explanation helpful. Specifically, the phrase that jets me out of my abilities of comprehension is "or rewrite specific extension nodes."

I understand the rest of it, which pertains to the reduction or breaking down of the expression into sub-expressions.

Also in the same namespace is an enumeration named ExpressionType, the purpose of which I understand very well. But of all its members, there is one member named Extension which I cannot map to any syntactical token I am currently aware of.

The documentation in this instance, too, is frustratingly laconic. It describes the value Extension as follows:

An extension expression.

It is obvious that the two -- ExpressionType.Extension and ExpressionVisitor.VisitExtension -- are related.

But what is an extension? Surely, as is glaringly obvious, extension methods have no place in this context. Which syntactical artifact does the expression extension refer to here?

Answer 1

In this case, extension does not represent any kind of built-in syntax, but correspond to nodes that applications can define and assign arbitrary meaning to.

That concept is very useful when one manipulates Expression trees in an application, as these extension nodes can be fully integrated into what is otherwise a normal expression tree.

For example, I defined a subclass of System.Linq.Expressions.Expression with node type ExpressionType.Extension in order to extend Entity Framework's LINQ to understand the type of composite primary key that was in use at my company.

The extension expression type was useful because it let me use a two-step approach:

• In the first step, an expression visitor would regularize every appearance of that composite key into a node of my custom type;
• In the second step, the expression visitor that was tasked with translating the expression to something that Entity Framework would be able to handle could simply check on the type;

Example: let us say that I had LINQ code that was written:

from e in table where e.FirstKey == e.SecondKey select e;

Where FirstKey and SecondKey were both composite database keys (that is, there are two database columns FirstKey1 and FirstKey2 for FirstKey, and similarly for SecondKey).

Then the first visitor would transform both e.FirstKey and e.SecondKey to CustomKeyExpression nodes, functionally transforming it to:

from e in table where Key(e.FirstKey1, e.FirstKey2) == Key(e.SecondKey1, e.SecondKey2) select e;

And in the second visitor, when I would visit EqualExpression, I would check that both children were CustomKeyExpressions, and make the appropriate transformation:

from e in table where e.FirstKey1 == e.SecondKey1 && e.FirstKey2 == e.SecondKey2;