修改 .NET 对象使其在 IronPython 中表现出动态性

假设你要和一个 .NET 的库进行互操作，但同时你又想让它表现的像动态语言中的对象那样，你想动态的给对象添加/删除方法或属性。在 python 中你可以这样写：

class x(object):
    pass

y = x()
y.z = 42
dir(y)

这样 dir(y) 就会包含 z. 如果 x 是 .NET 类而不是一个 python 类呢，能做到这一点吗？让我们尝试一个简单的 .NET 类：

public class TestExt
{
}

在 IronPython 中你可以这样:

import clr
clr.AddReference("TestExtensions.dll")
from TestExtensions import TestExt
y = TestExt()
y.z = 42

但这个代码会抛出 AttributeError，提示 'TestExt' 不存在属性 'z'。现在该怎么办呢？这正是 DLR 的扩展机制所要做的。有5个方法可以让 .NET 类来实现，这些方法可以对 binder 显示特殊含义，它们是：

• GetCustomMember – 在常规的 .NET 查找前执行
• GetBoundMember – 在常规的 .NET 查找后执行
• SetMember – 在常规的 .NET 成员赋值前执行
• SetMemberAfter – 在常规的 .NET 成员赋值后执行
• DeleteMember – 在常规的 .NET 操作符访问之前执行（没有对应的 .NET 版本 —— 因此是唯一的一个）

.NET 类可以实现这些函数，并用 SpecialName 特性 来标注它们。现在绑定规则可以在常规 .NET 绑定的前后，调用 Getter/Setter. GetCustomMember/SetMember 首先被调用，并且，如果它返回一个值，则会被当作成员查找的返回值。这就可以覆盖任意可能存在的 .NET 成员。但如果你从该函数中返回 OperationFailed.Value，就会按常规方法继续进行查找。GetBoundMember/SetMemberAfter 在常规调用失败的时候会被调用到 —— ‘失败’表示不存在要绑定到的名字的成员。记住这些，我们来修改一下 .NET 类，向其中添加一些东西：

Dictionary<string, object> dict = new Dictionary<string, object>();
[SpecialName]
public object GetBoundMember(string name)
{
    if (dict.ContainsKey(name))
        return dict[name];
    else
        return OperationFailed.Value;
}

[SpecialName]
public void SetMemberAfter(string methodName, object o)
{
    dict.Add(methodName, o);
}

现在如果我尝试 y.z = 42, 代码会成功运行。同样我可以把 y.z 设定为一个函数，这样就可以调用 y.z() 了。换一种方法，我也可以重写 GetCustomMember 和 SetMember 方法来实现，例子一样有效，因为如果在 dict 中查找不到成员就会返回 OperationFailed.Value. 但这会带来一个负担，就是会影响到所有 .NET 成员的查找过程。

SetMember 函数可以返回 bool 而不是 void. 如果返回 bool 值，这个返回值会控制是否继续进行绑定查找。

那么，这个特性的作用是什么？我为什么要用它呢？假设我们要写一个类似下面 xml 所表示的对象模型：

[assembly: ExtensionType(typeof(System.Xml.XmlElement), typeof(TestExtensions.ExtClass.XmlElementExtension))]
namespace TestExtensions
{    
    public class ExtClass
    {
        static ExtClass()
        {
            Microsoft.Scripting.Runtime.RuntimeHelpers.RegisterAssembly(typeof(ExtClass).Assembly);
        }

        public static XmlElement Load(string fileName)
        {
            XmlDocument doc = new XmlDocument();
            doc.Load(fileName);
            return doc.DocumentElement;
        }
        public static class XmlElementExtension
        {
            [SpecialName]
            public static object GetCustomMember(object myObj, string name)
            {
                XmlElement xml = myObj as XmlElement;

                if (xml != null)
                {
                    for (XmlNode n = xml.FirstChild; n != null; n = n.NextSibling)
                    {
                        if (n is XmlElement && string.CompareOrdinal(n.Name, name) == 0)
                        {
                            if (n.HasChildNodes && n.FirstChild == n.LastChild && n.FirstChild is XmlText)
                            {
                                return n.InnerText;
                            }
                            else
                            {
                                return n;
                            }

                        }
                    }
                }
                return OperationFailed.Value;
            }
        }
    }
}

现在，在 IronPython 中可以这样写：

import clr
clr.AddReference("TestExtensions.dll")
from TestExtensions import ExtClass
foo = ExtClass.Load("test.xml")
print foo.bar

但是VS2008针对这三个动态语言的模板还没有完成，所以现在我们没有办法创建动态语言的Silverlight 2项目（甚至于VB的都不行，默认只是C#的）；不过Silverlight 2 SDK提供了一个工具来帮助我们生成部署的xap文件——Chiron工具，它在目录：C:\Program Files\Microsoft SDKs\Silverlight\v2.0\Tools\Chiron里。

另外，在CodePlex上还提供了一个Dynamic Silverlight Sample的项目，来指导我们在Silverlight 2中使用动态语言，不过目前这个项目还是针对Silverlight 1.1的。

下面我就给大家演示一下（以IronPython为例）：

• 创建一个目录，如IPSL2，在里面创建2个子目录：app（包含动态语言代码文件和XAML文件文件）和assets（包含资源文件，如图片等）；在assets中在创建一个子目录js（这个目录其实可以不要，在1.1中是用于保存silverlight.js的，不过现在可以保存其他js文件）。
• 在app目录中创建一个IronPython代码文件：app.py，代码如下（在这里，我是使用XamlReader.Load把xaml字符串直接加载，本来我想用Application.Current.LoadRootVisual方法把app.xaml载入，但是一直没有成功，有朋友知道怎么弄吗？）：

from System.Windows import Application
from System.Windows.Markup import XamlReader

Application.Current.RootVisual = XamlReader.Load("""
<Canvas xmlns="http://schemas.microsoft.com/client/2007"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">

    <TextBlock x:Name="message" FontSize="30"/>

</Canvas>""")

Application.Current.RootVisual.message.Text="Welcome to Silverlight and IronPython!"

• 在app目录中创建一个xaml代码文件：app.xaml（在我的例子中，可以不要这个文件，但是如果使用LoadRootVisual方法的话，就需要），代码如下：

<Canvas xmlns="http://schemas.microsoft.com/client/2007"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">

    <TextBlock x:Name="message" FontSize="30"/>

</Canvas>

• 在根目录中，本例即IPSL2目录中，创建一个Index.html文件来作为浏览页面，body中的代码如下（解释一下，我这里为什么要用图片的原因，这是因为在Windows Live Writer中贴入一下代码后，就在其中显示一个Silverlight的控件了，真是的！）：

• 现在开始使用Chrion工具来运行这个动态语言Silverlight 2应用程序了。
• 首先，把Chrion所在的目录添加到PATH中
• 启动命令行，进入到IPSL2目录中，运行Chrion /b来启动一个Web Server，并同时打开一个浏览器
• 在浏览器中点index.html文件，就可以看到Silverlight over IronPython的应用程序运行了，如下图：

另外对于使用IronRuby的同学来说，可以参考John Lam的文章（注：下面我给的连接是通过Web代理访问，直接是访问不了的）：

John Lam on Software Dynamic Silverlight Part 1 Hello, World!

John Lam on Software Dynamic Silverlight Part 2 Managed JScript and flickr

整个示例的代码在这里下载：http://www.91files.com/?GXW6W7RN1L2N1N358LJC

Update!
对于app.py和app.xaml得到思归的提醒，可以使用如下代码（其实一下代码，我昨晚也尝试过，结果没有成功，简直晕死！）：
app.py：
============
from System.Windows import Application
from System.Windows.Controls import UserControl

Application.Current.LoadRootVisual(UserControl(), 'app.xaml')

Application.Current.RootVisual.message.Text="Welcome to Silverlight and IronPython!"
============
app.xaml：
============
<UserControl
   xmlns="http://schemas.microsoft.com/client/2007"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
   x:Class="System.Windows.Controls.UserControl"
   x:Name="Page" >

    <TextBlock x:Name="message" FontSize="30"/>

 Download IronPython v2.0 Alpha 3

Note: Due to dependencies upon APIs that are not present in Silverlight 1.1 Alpha (released at MIX) you won’t be able to re-build this release for use with Silverlight. As both products stabilize more we expect better compatibility between releases.

下载:IronPython 2.0 Alpha2

Note: Due to dependencies upon APIs that are not present in Silverlight 1.1 Alpha (released at MIX) you won’t be able to re-build this release for use with Silverlight. As both products stabilize more we expect better compatibility between releases.

Hello IronPython Community,

We have just released IronPython 2.0 Alpha 1. IronPython 2.0 will be the first release of IronPython built upon a common dynamic language runtime (DLR) as well as targeting version 2.5 of Python. These release notes list what is new in IronPython 2.0, a brief overview of the DLR, and what to expect from the 2.0 release.

One major focus during this release will be further improving our conformance with CPython. We’ve already made several improvements, for example one is that our type system no longer contains a hierarchy of types: now type(type) is type. We have also fixed a number of issues related to various statements such as imports and function definitions inside of exec or eval. There have also been a number of other small issues fixed that our users reported to us.

IronPython 2.0 will also be the first major release to support 2.5 out of the box. In IronPython 1.x, and in this initial alpha release, users must enable this with a command line switch. During the 2.0 release cycle we will flush out the remaining 2.5 features and permanently enable this option. We will also start looking at supporting v2.6 features via command line switch and start some experimentation around the 3.0 features. In particular, we are excited about looking at the new bytes and string types as well as formatting options that we believe will fit nicely with .NET.

IronPython 2.0 is also the first release built upon the Dynamic Language Runtime: a shared runtime for dynamic languages on .NET. The DLR both reduces the amount of work to create new dynamic languages on .NET enables rich interoperability between dynamic languages, and provides a shared module for consuming those languages from applications. We are particularly excited about the ability to share code across dynamic languages enabling users to share libraries without worrying the particular language in which the library is written. Over time, the DLR will expand and improve bringing language developers more benefits from this shared infrastructure. We also look forward to seeing a new era of programmable apps that can support a wide range of options for end-users.

When we started working on the DLR we initially used the IronPython v1.0 code base. From there we extracted the core concepts that were common to dynamic languages, generalized the concepts that were specific to Python, expanded the framework to provide rich support for other dynamic languages, and exposed all of the languages via a common interface. Starting with IronPython 1.0 was an obvious choice because it had already captured many of the best practices for building dynamic languages on .NET and had done a great job leveraging many of the underlying features of .NET. In IronPython 2.0 all of these best practices are expanded and implemented with an eye on maximizing forward compatibility with new features in .NET v3.5 such as LINQ and extension methods. Moreover, the DLR exposes this functionality to the language implementer via a small set of core concepts that all dynamic language implementations can share.

One additional change in this release is that we’re moving to use the Microsoft Permissive License for IronPython 2.0. Our original release of IronPython predated the Microsoft Permissive License, and so we created a custom license specifically for Iron Python. After releasing Iron Python, we created new Microsoft Shared Source licenses, including the Microsoft Permissive License, to facilitate and standardize source code licensing for appropriate Microsoft projects. We believe our users appreciate consistency in licensing from Microsoft. Therefore, because we are now using the more modern Microsoft Permissive License where appropriate for similar current source code releases, we feel we should offer IronPython under the Microsoft Permissive License as well.

Note because this is an alpha release there is also some missing functionality that was formerly present in v1.0. This includes CodeDom support, the static compiler that produced .NET assemblies, support for creating strongly typed delegates to script code, as well as a drastically changed hosting API. We will be bringing this functionality back to future releases in the IronPython 2.0 series as well many other improvements.
You can download IronPython v2.0 at: 2.0 Alpha

If you’d like more details about the DLR, Jim will be using his blog to post design notes as they are written over the next couple of weeks – http://blogs.msdn.com/hugunin.
===================================

pypy provides infrastructure for building interpreters in [r]python. This infrastructure makes it much easier than starting from scratch, e.g. by providing reusable components for language runtimes (like GC's).

>>> for caseType in myAsm.MainModule.Types:
     print caseType

<Module>
CecilCase.MainCase
CecilCase.SecondCase

So <Module> was the hidden type. We'll ignore it from now on.

>>> for caseType in myAsm.MainModule.Types:
     if caseType.Name != '<Module>':
         print caseType.Name

MainCase
SecondCase

>>> mainCaseType.Methods.Count
4
>>> for met in mainCaseType.Methods:
     print met.Name

PublicMethod
AddMethod
PrivateMethod
MethodWithArgument

>>> for met in mainCaseType.Methods:
     print met

System.Void CecilCase.MainCase::PublicMethod()
System.Void CecilCase.MainCase::AddMethod()
System.Void CecilCase.MainCase::PrivateMethod()
System.Void CecilCase.MainCase::MethodWithArgument(System.String)

Instructions（译者注：Instructions就是IL语句的序列，它是一个集合对象，我们需要枚举它。

>>> for ins in pMet.Body.Instructions:
     print ins

Mono.Cecil.Cil.Instruction
Mono.Cecil.Cil.Instruction
Mono.Cecil.Cil.Instruction
Mono.Cecil.Cil.Instruction
Mono.Cecil.Cil.Instruction
Mono.Cecil.Cil.Instruction
Mono.Cecil.Cil.Instruction
Mono.Cecil.Cil.Instruction
Mono.Cecil.Cil.Instruction
Mono.Cecil.Cil.Instruction
Mono.Cecil.Cil.Instruction
Mono.Cecil.Cil.Instruction

好，它显示出了我们期望的结果。如果你尝试看看ins是否具有智能感知功能的话，目前是无法正常工作的。所以，我们需要添加从Cecil命名空间中添加所有类型。

>>> from Mono.Cecil.Cil import *

>>> for ins in pMet.Body.Instructions:
     print ins.OpCode.Name

nop
ldstr
call
nop
ldarg.0
call
nop
newobj
ldstr
call
nop
ret

我们来和Reflector的反编译输出结果比较一下：



很酷吧！基本使用我们介绍到这里。接下来，我们将开始关注3个“call”语句（译者注：call语句指的是上图所显示出的IL语句）。

>>> for ins in pMet.Body.Instructions:
     if ins.OpCode.Name == 'call':
         ins.Operand

<Mono.Cecil.MethodReference object at 0x000000000000003F [System.Void System.Console::WriteLine(System.String)]>
<Mono.Cecil.MethodDefinition object at 0x0000000000000031 [System.Void CecilCase.MainCase::PrivateMethod()]>
<Mono.Cecil.MethodDefinition object at 0x000000000000003D [System.Void CecilCase.SecondCase::Help(System.String)]>

以上得到了Operand的细节。现在，我们需要得到这方法的定义对象以便我们能递归的浏览每一个子方法。为了达到目的，我们定义了一个方法，它能把传入的

>>> def parseMethodBody(methodDef):
     for ins in methodDef.Body.Instructions:
         if ins.OpCode.Name == 'call':
             print ins.Operand

>>> for ins in pMet.Body.Instructions:
     if ins.OpCode.Name == 'call':
         parseMethodBody(ins.Operand)

Traceback (most recent call last):
  File , line 0, in <stdin>##168
  File , line 0, in parseMethodBody
AttributeError: 'MethodReference' object has no attribute 'Body'

>>> def parseMethodBody(mDef):
     if isinstance(mDef, MethodDefinition):
         for ins in mDef.Body.Instructions:
             if ins.OpCode.Name == 'call':
                 print ins.Operand


>>> for ins in pMet.Body.Instructions:
     if ins.OpCode.Name == 'call':
         parseMethodBody(ins.Operand)

1. 在添加Mono.Cecil的引用之后用AssemblyFactory来加载程序集
2. 得到需要的类型
3. 得到需要的方法
4. 得到Instructions（只需要得到“call”）
5. 得到每一个“call”的Operand信息

>>> for inst in pMet.Body.Instructions:
     if inst.OpCode.Name == 'call':
         parseMethodBody(inst.Operand)

System.Void System.Console::WriteLine(System.String)
System.Void CecilCase.SecondCase::HelpMeToo(System.String)