一个真实的对象(第一部分)
2007-06-26 17:17
267 查看
本文翻译自IronPython的作者Jim Hugunin的个人博客,原文链接为 http://blogs.msdn.com/hugunin/archive/2007/05/02/the-one-true-object-part-1.aspx
我非常兴奋,因为看到了大家想要了解DLR的热情。我也要说对不起,因为现在现没有完整的文档给你们。如果你想要一分详尽的文档和API,你还要等一段时间。如果你喜欢源代码和这个Blog,那么你可以开始在这里浪费点时间了。如果你只是想尝试一下代码,去下载silverlight,开始探索构建在DLR之上的Python和JavaScript吧。
今天我的设计笔记是关于动态类型系统的。动态类型系统是DLR的三个关键组件之一——而且我认为是最关键的。DLR的里程牌便是支持一个共享的动态类型系统。这使得动态语言之间可以容易而自然地相互交流,共享代码。同样重要的是我们使这些动态语言能够工作在现有的强大的静态语言平台上,例如VB.NET和C#.我们要确保现有的和以后为.NET写的库都能够为动态语言服务。为了实现这种互操作,有一种标准的模式——通过包装(wrapper)和管制层。我利用这个模式实现了Jython——JVM上的Python。
注意到在这个模式中,Python类型存在于它们自己的小世界中(桔色部分),而且对于每个底层的类型,我都需要把它放到一个Python特性的包装类中。如果只是想支持一种语言,这个模式是很好的。在我上面这个例子中,我只写Python代码,那么所有我处理的对象都是PyObject,它们可以相互工作的很好,通过它们的Python特性。可是当你想支持多种语言的集成时,这个模式就会崩溃了。在这种情况下,每一次一个对象从一种语言移动到另一种语言时,它需要从源语言去包装,再包装到目标语言。这会带来明显的性能问题,当跨语言调用时包装类被创建被丢弃。
这个包装的方法还有更深层次的问题。一个挑战便是我们要指出需要传递的对象。例如,Python中有PyString,当调用C#函数时需要一个对象时,是应该传递PyString还是解包装为String?这些微妙的问题从来没有一个好的答案。更糟的,在程序员后面静悄悄的包装和解包装的过程中,对象同一性的缺失会产生更讨厌的问题。
大多数流行的用C实现的动态语言同样使用包装模式。当用C来实现动态语言时,这种包装是很合理的,因为C指针没有携带任何运行时有用的类型信息,所以需要一个包装层来提供需要的运行时类型信息。但是,托管的运行时,例如CLR,为它们的标准对象提供了丰富的运行时类型信息,所以应该可能直接使用这个对象,没有包装和和管制带来的混乱和运行代价。我们在DLR中使用了这一点,这也是我们实际应用的类型系统。
这意味着DLR中的所有对象和CLR的对象是完全一致的。我们添加了更好的支持公共动态操作的特性,但我们仍然深深地植根于.NET上现存的库和语言。如果想要真正的使语言之间无缝整合,我们需要一个统一的类型系统,不用管制和包装层。
现在我们到达了第一部分的终点,我担心这也许会令人不满意。到现在为止,我们关于动态类型系统的解释就是,我们使用的对象和元数据完全是CLR上已经使用的静态的类型化的对象。好吧,今天在网上的发布不会让我停止。更多关于CLR上的动态类型系统的细节我会在下面讨论。
我非常兴奋,因为看到了大家想要了解DLR的热情。我也要说对不起,因为现在现没有完整的文档给你们。如果你想要一分详尽的文档和API,你还要等一段时间。如果你喜欢源代码和这个Blog,那么你可以开始在这里浪费点时间了。如果你只是想尝试一下代码,去下载silverlight,开始探索构建在DLR之上的Python和JavaScript吧。
今天我的设计笔记是关于动态类型系统的。动态类型系统是DLR的三个关键组件之一——而且我认为是最关键的。DLR的里程牌便是支持一个共享的动态类型系统。这使得动态语言之间可以容易而自然地相互交流,共享代码。同样重要的是我们使这些动态语言能够工作在现有的强大的静态语言平台上,例如VB.NET和C#.我们要确保现有的和以后为.NET写的库都能够为动态语言服务。为了实现这种互操作,有一种标准的模式——通过包装(wrapper)和管制层。我利用这个模式实现了Jython——JVM上的Python。
注意到在这个模式中,Python类型存在于它们自己的小世界中(桔色部分),而且对于每个底层的类型,我都需要把它放到一个Python特性的包装类中。如果只是想支持一种语言,这个模式是很好的。在我上面这个例子中,我只写Python代码,那么所有我处理的对象都是PyObject,它们可以相互工作的很好,通过它们的Python特性。可是当你想支持多种语言的集成时,这个模式就会崩溃了。在这种情况下,每一次一个对象从一种语言移动到另一种语言时,它需要从源语言去包装,再包装到目标语言。这会带来明显的性能问题,当跨语言调用时包装类被创建被丢弃。
这个包装的方法还有更深层次的问题。一个挑战便是我们要指出需要传递的对象。例如,Python中有PyString,当调用C#函数时需要一个对象时,是应该传递PyString还是解包装为String?这些微妙的问题从来没有一个好的答案。更糟的,在程序员后面静悄悄的包装和解包装的过程中,对象同一性的缺失会产生更讨厌的问题。
大多数流行的用C实现的动态语言同样使用包装模式。当用C来实现动态语言时,这种包装是很合理的,因为C指针没有携带任何运行时有用的类型信息,所以需要一个包装层来提供需要的运行时类型信息。但是,托管的运行时,例如CLR,为它们的标准对象提供了丰富的运行时类型信息,所以应该可能直接使用这个对象,没有包装和和管制带来的混乱和运行代价。我们在DLR中使用了这一点,这也是我们实际应用的类型系统。
这意味着DLR中的所有对象和CLR的对象是完全一致的。我们添加了更好的支持公共动态操作的特性,但我们仍然深深地植根于.NET上现存的库和语言。如果想要真正的使语言之间无缝整合,我们需要一个统一的类型系统,不用管制和包装层。
现在我们到达了第一部分的终点,我担心这也许会令人不满意。到现在为止,我们关于动态类型系统的解释就是,我们使用的对象和元数据完全是CLR上已经使用的静态的类型化的对象。好吧,今天在网上的发布不会让我停止。更多关于CLR上的动态类型系统的细节我会在下面讨论。
相关文章推荐
- 将请求做一个真实的命令对象来对待很便捷
- 认识一个对象的真实面目(什么类)
- 线程对象——第一部分
- MVC C#在后台接收一个气象台Json,在前台可以弹出json中所有的数据,但是现在想获取气象Json中每一个对象
- 获取一个对象的属性/属性值,以及动态给属性赋值
- 关于Objective-C 对象release操作的一个小问题探讨
- javascript判断一个变量或对象是否存在
- final关键字修饰一个变量时,是引用不能变,还是引用的对象不能变
- 离职员工真实感受:告诉你一个真实的360
- Java计算一个对象占用内存的大小
- 每个线程调用的是同一个ThreadTest对象
- 只能生成一个对象的类(经典设计模式之一)
- 一个真实的故事:IT人离开IT还能干什么
- 使用构造函数来判断一个对象是数组还是日期
- java创建一个对象步骤
- Windows核心编程学习笔记 第一部分 第三章 内核对象
- 将一个view对象转换为bitmap对象
- 代码库:把一个view转化成bitmap对象
- 编写一个小程序,从标准输入读入一系列string对象,寻找连续重复出现的单词。程序应该找出满足一下条件的单词:该单词的后面紧接着再次出现自己本身。跟踪重复次数最多的单词及其重复次数,输出.
- 当使用System,out.println()打印一个对象是自动调用toString方法