表达式即编译器

阅读数:4992 2009 年 9 月 22 日

话题:.NET语言 & 开发

介绍:问题所在

无论你是否喜欢反射,很多情况下你不可避免地会需要在运行时(而不是编译时)访问一个类型的成员。可能你在尝试着编写一些验证、序列化或是 ORM 代码,也可能必要的属性或方法是在运行时从配制文件或数据库中获得的。无论是什么原因,你在某些时候一定写过GetType() ——就像这样:

Type type = obj.GetType(); 
foreach (var property in type.GetProperties())
 
{ 

    Console.WriteLine("{0} = {1}", 

       property.Name, 

       property.GetValue(obj, null)); 

} 

虽说这个普通的示例可以正常工作,但它不够理想——这里有一些关键性的问题:

  • 它比较慢——你偶尔使用的话还好,但是在密集的循环中就会有明显的差距了。
  • 没有比较方便的做法把那些准备工作“打包”成可复用的代码。

而且,在动态代码的需求变复杂时,情况则会更加糟糕。

当然,一个明显的应对方式是“不要使用反射”——例如,手动(或使用代码生成工具)为每个类型写一个方法来做对应的事情。表面看来这种简单的做法没有问题,但是这会导致大量的重复代码,而且也无助于我们使用编译期间还不可知的类型。

我们需要的是某种形式的元编程(meta-programming)API。幸运的是,在.NET 2.0 中提供 Reflection.Emit 来动态编写 IL(Java“二进制码(bytecode)”在.NET 中的对应物),不过这也要求开发人员直接处理所有细微的装箱、类型转换、调用堆栈细节或操作符“提升”等操作——简而言之,你需要了解大量本不需要知道的 CLI 内容。另一个选择是 CodeDom,不过这也是一种显式的代码生成方式,我们想要的做的事情往往会淹没在大量构造 CodeDom 所需要的繁琐事务中。

我们需要的是一种折衷的方案,一种足够高的抽象让我们不必关心实际的 IL 如何,但也不能过于高级:我们的代码想要尽可能的简单并富于表现力。

背景:走近 System.Linq.Expressions.Expression

微软在.NET 3.5 中引入了 LINQ。LINQ 的关键部分之一(尤其是在访问数据库等外部资源的时候)是将代码表现为表达式树的概念。这种方法的可用领域非常广泛,例如我们可以这样筛选数据:

var query = from cust in customers

            where cust.Region == "North"

            select cust;

虽然从代码上看不太出彩,但是它和下面使用 Lambda 表达式的代码是完全一致的:

var query = customers.Where(cust => cust.Region == "North");

LINQ 以及 Where 方法细节的关键之处,便是 Lambda 表达式。在 LINQ to Object 中,Where 方法接受一个 Func<T, bool> 类型的参数——它是一个根据某个对象(T)返回 true(表示包含该对象)或 false(表示排除该对象)的委托。然而,对于数据库这样 的数据源来说,Where 方法接受的是 Expression<Func<T, bool>> 参数。它是一个表示测试规则的表达式树,而不是一个委托。

这里的关键点,在于我们可以构造自己的表达式树来应对各种不同场景的需求——表达式树还带有编译为一个强类型委托的功能。这让我们可以在运行时轻松编写 IL。

那么,什么是一个表达式树?

与一般情况下 C# 编译得到的 IL 不同,一个 Lambda 表达式会被编译为一个表现代码逻辑的对象模型。于是,例如数据库提供者(provider)便可以观察这个对象模型,理解我们编写代码的目的,在必要时便可以将这种目的转化为其他形式(如 T-SQL)。

我们不妨独立观察先前的 Lambda 表达式:

Expression<Func<Customer, bool>> filter =
    cust => cust.Region == "North";

如果要观察编译器做的事情,我们需要如平时般编译示例代码(Lambda 表达式),然后在强大(且免费)的Reflector中查看——不过在此之前,我们要将.NET 3.5 (C# 3.0) 优化选项关闭。

然后观察反编译器的输出内容,就会发现一些原本应该由我们自己编写的 C# 代码:

请注意,虽然编译器直接访问了 MemberInfo 对象,并且使用了非法的变量名——所以你无法直接让这些输出编译通过,它只是用来参考的。有趣的是,事 实上 C# 语言规范中并没有指明编译器是如何将代码转化为表达式树的,因此,使用编译结果作为参考实现,是为数不多的可用于研究表达式树的方法之一。

为了研究表达式树的手动编写方法,我们需要把相等性判断(==)和成员访问(.)视为接受运算对象的普通方法:

Expression<Func<Customer, bool>> filter =
    cust => Equal(Property(cust,"Region"),"North"); 

我们现在可以构建一个相同的,接受 Customer 类型作为参数,判断其 Region 属性是否为字符串“North”,并返回一个布尔值的表达式树。

// declare a parameter of type Customer named cust

ParameterExpression cust = Expression.Parameter(

    typeof(Customer), "cust");

// compare (equality) the Region property of the

// parameter against the string constant "North"

BinaryExpression body = Expression.Equal( Expression.Property(cust, "Region"), Expression.Constant("North", typeof(string))); // formalise this as a lambda

Expression<Func<Customer, bool>> filter = Expression.Lambda<Func<Customer, bool>>(body, cust);

最后的“Lambda”语句是将表达式树标准化为一个完全独立的单元,并包含一系列(这个例子中只有一个)用于表达式树内部的参数。如果我们传入一个 Lambda 内不存在的参数,则会抛出一个异常。

一个表达式树,其实只是一个表现我们意图的不可变的对象模型:

  • filter (lambda)
    • parameter: Customer: “cust”
    • body (binary)
      • method: equals
      • left (member)
        • member: “Region”
        • expression: “cust” parameter
      • right (constant)
        • string: “North”

在获得一个完整的表达式树之后,我们可以将其交由 LINQ 提供者处理(此时它就会被真正当作一颗“树”来处理了),或者把它编译为一个委托——即动态生成所需的 IL:

Func<Customer, bool> filterFunc = filter.Compile(); 

现在我们向委托对象中传入一个 Customer 实例并返回一个布尔值。

这看上去有些麻烦,但已经远比使用 Reflection.Emit 的方式来的简单了,尤其在一些较为复杂的情况下(如装箱)。

重要:将一个表达式树编译为委托对象涉及到动态代码的生成。如果想要获得最佳的性能,你应该仅编译一次——将其储存起来(如放在一个字段中)并复用多次。

Expression 的妙用

到目前为止,我们只是观察了一个用 C# 就能完成的简单示例——这自然没什么大不了的。所以我们现在来看一些 C# 无法做到的东西……我经常被人问及,有什么 方法可以编写一个通用的“加法”操作,可以对任意类型进行计算。简而言之:没有这样的语法。不过我们可以使用 Expression 来做到这一点。

简单起见,我使用 var 关键字来代替显式变量类型,我们现在将要观察如何简单地缓存可重用的委托对象:

public static class Operator<T>
{
    private static readonly Func<T, T, T> add;
    public static T Add(T x, T y)
    {
        return add(x, y);
    }
    static Operator()
    {
        var x = Expression.Parameter(typeof(T), "x");
        var y = Expression.Parameter(typeof(T), "y");
        var body = Expression.Add(x, y);
        add = Expression.Lambda<Func<T, T, T>>(
            body, x, y).Compile();
    }
}

因为我们在静态构造函数中编译委托对象,这样的操作只会为每个不同的类型 T 执行一次,接着便可重用了——所以对于任何代码我们现在都可以直接使用 Operator<T>。有趣的是,这个简单的“Add”方法隐藏了许多复杂性:值类型或引用类型、基础操作(直接有 IL 指令与之对应)、隐 藏操作符(方法为类型定义的一部分)以及提升操作(用于自动处理 Nullable<T>)等等。

这个做法甚至支持用户自定义类型——只要你为它定义了 + 运算符。如果没有合适的运算符,这段代码便会抛出异常。在实际使用过程中这不太会是个问题,如果你不放心的话,可以在 Add 外加上 try 语句进行保护。

MiscUtil类库提供了完整的通用操作符实现。

Expression 支持哪些东西?

在.NET 3.5 中,Expression 支持完整的用于查询或创建对象的操作符。

  • 算术运算:Add, AddChecked, Divide, Modulo, Multiply, MultiplyChecked, Negate, NegateChecked, Power, Subtract, SubtractChecked, UnaryPlus
  • 对象创建:Bind, ElementInit, ListBind, ListInit, MemberBind, MemberInit, New, NewArrayBounds, NewArrayInit
  • 二进制运算:And, ExclusiveOr, LeftShift (<<), Not, Or, RightShift (>>)
  • 逻辑运算:AndAlso (&&), Condition (? :), Equal, GreaterThan, GreaterThanOrEqual, LessThan, LessThanOrEqual, NotEqual, OrElse (||), TypeIs
  • 成员访问:ArrayIndex, ArrayLength, Call, Field, Property, PropertyOrField
  • 其他:Convert, ConvertChecked, Coalesce (??), Constant, Invoke, Lambda, Parameter, TypeAs, Quote

例如,我们可以用设置公开属性的方式实现浅克隆——最简单的做法可以这样写:

person => new Person 

{  

    Name = person.Name,  

    DateOfBirth = person.DateOfBirth, ...  

}; 

对于这种情况,我们需要使用 MemberInit 方法:

private static readonly Func<T, T> shallowClone; 

static Operator() 

{ 

     var orig = Expression.Parameter(typeof(T), "orig");
 

     // for each read/write property on T, create a 

// new binding (for the object initializer) that

// copies the original's value into the new object

var setProps = from prop in typeof(T).GetProperties ( BindingFlags.Public | BindingFlags.Instance) where prop.CanRead && prop.CanWrite select (MemberBinding) Expression.Bind( prop, Expression.Property(orig, prop)); var body = Expression.MemberInit( // object initializer Expression.New(typeof(T)), // ctor

setProps // property assignments ); shallowClone = Expression.Lambda<Func<T, T>>( body, orig).Compile(); }

这种做法比标准的反射方式的性能要高的多,而且不需要为每种类型维护一段代码,也不会遗漏一些新增的属性。

类似的方法还可以用于其他一些方面,如在 DTO 对象之间映射数据,在类型与 DataTable 对象之间建立关系——或比较两个对象是否相等:

(x,y) => x.Name == y.Name &&
 
   x.DateOfBirth == y.DateOfBirth && ...; 

在这里我们需要使用 AndAlso 来结合每个操作:

private static readonly Func<T, T, bool> propertiesEqual;
static Operator()
{
   var x = Expression.Parameter(typeof(T), "x"); 

   var y = Expression.Parameter(typeof(T), "y"); 


   var readableProps =
 
       from prop in typeof(T).GetProperties( 

           BindingFlags.Public | BindingFlags.Instance) 

       where prop.CanRead 

       select prop; 


    Expression combination = null; 

    foreach (var prop in readableProps) 

    { 

       var thisPropEqual = Expression.Equal( 

           Expression.Property(x, prop), 

           Expression.Property(y, prop)); 


       if (combination == null) 

       { // first 

          combination = thisPropEqual; 

       } 

       else 

       { // combine via && 

            combination = Expression.AndAlso( 
                   combination, thisPropEqual); 

       } 

   } 


   if (combination == null) 
   { // nothing to test; return true 

       propertiesEqual = delegate { return true; }; 
   } 

   else 
   { 
       propertiesEqual = Expression.Lambda<Func<T, T, bool>>(
              combination, x, y).Compile();
   } 

} 

Expression 的限制——及展望

到目前为止,Expression 的表现几近完美——然而,还有 LINQ 表达式的构造方式还有许多明显的限制:

  • 没有内置的机制可以改变对象的属性 / 字段。
  • 没有方法可以执行一系列的操作

在上面的例子中,我们可以使用 AndAlso 将多个步骤连接成一个逻辑语句。然而,在.NET 3.5 中无法使用一个表达式树来表现如下的语句:

person.DateOfBirth = newDob; 

person.Name = newName; 

person.UpdateFriends(); 

person.Save(); 

我们之前看到的 Bind 操作只能在创建新对象时使用。我们可以获取 setter 方法,但是我们无法将多个方法调用串联起来(就像“流畅”API 那样,可惜目前没有)。

幸运的是,.NET 4.0 扩展了 Expression API,增加了新的类型和方法。这么做的目的是支持动态语言运行时(DLR,Dynamic Language Runtime)。这大大扩展了:

  • 修改操作:AddAssign, AddAssignChecked, AndAssign, Assign, DivideAssign, ExclusiveOrAssign, LeftShiftAssign, ModuloAssign, MultiplyAssign, MultiplyAssignChecked, OrAssign, PostDecrementAssign, PostIncrementAssign, PowerAssign, PreDecrementAssign, PreIncrementAssign, RightShiftAssign, SubtractAssign, SubtractAssignChecked
  • 算术操作:Decrement, Default, Increment, OnesComplement
  • 成员访问:ArrayAccess, Dynamic
  • 逻辑运算:ReferenceEqual, ReferenceNotEqual, TypeEqual
  • 逻辑流:Block, Break, Continue, Empty, Goto, IfThen, IfThenElse, IfFalse, IfTrue, Label, Loop, Return, Switch, SwitchCase, Unbox, Variable
  • 异常操作:Catch, Rethrow, Throw
  • 调试:ClearDebugInfo, DebugInfo

这对编写动态代码来说可谓是个天大的好消息(它甚至包含了将代码编译为 MethodBuilder 的能力,可生成动态类型)。例如,我们可以用它来编写一个简单的 for 循环来打印数字 0 到 9:

            var exitFor = Expression.Label("exitFor"); // jump label

var x = Expression.Variable(typeof(int), "x"); var body = Expression.Block(new[] { x }, // declare scope variables

Expression.Assign(x, Expression.Constant(0, typeof(int))), // init

Expression.Loop( Expression.IfThenElse( Expression.GreaterThanOrEqual( // test for exit x, Expression.Constant(10, typeof(int)) ), Expression.Break(exitFor), // perform exit

Expression.Block( // perform code Expression.Call( typeof(Console), "WriteLine", null, x), Expression.PostIncrementAssign(x) ) ), exitFor)); var runtimeLoop = Expression.Lambda<Action>(body).Compile();

虽然看上去似乎不是那么一鸣惊人,但如果您要在运行时编写编译好的代码,它比其他方式要方便和灵活得多。

之前我们通过属性复制来克隆一个对象——不过现在我们已经有能力把一个对象的数据复制给另一个对象了,这点对于 ORM 工具来说非常有用,例如跟踪一个对象的状态,执行外部更新,再提交这些改变。我们可以这么做:

            var source = Expression.Parameter(typeof(T), "source");

            var dest = Expression.Parameter(typeof(T), "dest");



            // for each read/write property, copy the source's value

// into the destination object

var body = Expression.Block( from prop in typeof(T).GetProperties( BindingFlags.Public | BindingFlags.Instance) where prop.CanRead && prop.CanWrite select Expression.Assign( Expression.Property(dest, prop), Expression.Property(source, prop))); var copyMethod = Expression.Lambda<Action<T,T>>( body, source, dest).Compile();

使用表达式在运行时创建类型

.NET 4.0 中有个有趣的功能:在此之前我们可以把一个 Expression 编译为一个独立的委托,而如今你可以在动态创建新类型时,使用 CompileToMethod 方法将一个表达式树作为方法体提供给一个 MethodBuilder 对象。这意味着,在未来我们可以方便地编写功能丰富的 类型(包括多态和接口实现),而不用直接接触 IL。

语言中的高级表达式

尽管运行时已经支持非常成熟的表达式树了,但是在 C# 4.0 中并没有额外的语言支持——所以我们只能手动创建表达式。这一般不会成为问题,因为几乎没有 LINQ 提供者会支持这些复杂表达方式。如果你在编译期 知道这些类型,不如直接编写普通的方法或匿名方法。不过这也为 4.0 以后的版本留下了想象空间。例如(只是推测),想象一下如果语言可以使用 Expression.Assign 和 Expression.Block 为数据库构造一个表达式树,就好比:

        // imaginary code; this doesn’t work

        myDatabase.Customers

             .Where(c => c.Region == "North")

             .Update(c => {

                 c.Manager = "Fred";

                 c.Priority = c.Priority + 10;

             });

再次强调这只是“假如”——这需要在 LINQ 提供者上耗费大量的工作,但是我们从中可以看出:理论上说,一个 Expression 对象是有能力来封装我们的意图的(更新实体的多个属性)。可惜,无论是语言还是框架都还有很长的路要走,只有时间可以说明一切。

阅读英文原文Expression as a Compiler


给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。