Anders Hejlsberg谈契约和协同工作能力

Contracts and Interoperability                                 契约和协同工作能力

A Conversation with Anders Hejlsberg, Part V              Anders Hejlsberg访谈之五

by Bill Venners with Bruce Eckel                                   采访者：Bill Venners、Bruce Eckel

November 3, 2003                                                        时间：2003-11-3

 

Summary

Anders Hejlsberg, the lead C# architect, talks with Bruce Eckel and Bill Venners about DLL hell and interface contracts, strong names, and the importance of interoperability.

提要：

Anders Hejlsberg是C#的首席设计师，在Bruce Eckel和Bill Venners对他的本次采访中，他谈到了“DLL地狱”和契约理论、强名称以及协同工作能力。

 

 

DLL Hell and the Theory of Contracts

“DLL地狱”和契约理论

 

Bill Venners: To what extent is "DLL Hell" a failure of interface contracts to work adequately in practice? If everyone fully understands and adheres to the contract of the functions of a particular DLL, shouldn't updating that DLL in theory not break any code?

在多大程度上讲，“DLL地狱”是接口契约在实际中充分工作时的一个失败？假如每个人都完全理解并且遵循特定DLL的功能契约，那么在理论上，是否不应该升级DLL，以避免对某些代码的破坏？

 

Anders Hejlsberg: Hell has many tortures. One aspect of DLL hell is that you don't adhere to your promised semantic contract. You do something different than what you did before, and therefore you break code. That's actually probably not the biggest issue that we face. The true problem with DLL hell is that we don't allow you to have multiple different versions of a particular DLL present on the machine. Once you upgrade the DLL you upgrade everybody, and that's a mighty big hammer.

“DLL地狱”让我们倍受折磨。一方面，你不会遵循你先前承诺的语义契约，你要做些和以前不同的事情，这样你就破坏了代码。可能这还不是我们面对的最大问题。“DLL地狱”的真正麻烦是我们不允许你在同一台计算机上放置一个DLL的多个不同版本。一旦你更新了这个DLL，你就必须给所有用户升级，这是非常巨大的工作量。

 

Bill Venners: But if the contract is followed, shouldn't the most recent version work for all users of that DLL?

那么，为了遵循契约，最新版本就不应该为该DLL的所有用户工作了？

 

Anders Hejlsberg: In theory, yes. But any change is potentially a breaking change. Even a bug fix could break code if someone has relied on the bug. By the strictest definition you realize that you can do nothing once you've shipped.

理论上来说，是这样的。但任何一个修改都可能具有潜在的破坏性。甚至一个bug修正也能破坏代码，如果用户对此bug已有依赖性。通过最严格的定义，你会认识到，一旦已经发布了（DLL），就不再能对它做任何修改。

 

Versioning is all about relaxing the rules in the right way and introducing leeway. The absolute answer, the only way guaranteed to not break anything, is to change nothing. It is therefore important to support side-by-side execution of multiple versions of the same functionality, on the same box or even in the same process. Side-by-side execution is one option we support in .NET that we didn't support in the older DLL model.

采用正确的方法，并作些折衷，那么通过对版本的控制，将可以放松这一限制。如果要绝对答案，那么保证不产生破坏性的唯一办法就是什么也不要改动。因此，对同样功能的多个版本的并行执行——在同样一个“匣子”，甚至过程里——的支持就非常重要。并行执行是我们在.NET中支持的一种功能，以前的DLL模式中是不提供的。

 

 

Strong Names in .NET

.NET中的强名称

 

Bill Venners: I assume you use strong names to identify the library version that you want. How do strong names work?

我猜测你是使用强名称来标识需要的链接库的版本。那么强名称是如何工作的呢？

 

Anders Hejlsberg: Strong names have a logical and physical part. The logical part is composed of the namespace and class names. Actually, from the Common Language Runtime's [CLR's] perspective, namespaces don't really exist. We can pretend that namespaces exist in the programming language, but from the CLR's perspective, a class name may have dots in it. That's the logical name of the class. The physical name includes the name of the assembly that the code lives in, the version number, the locale, and the cryptographic key associated with the name.

强名称分为逻辑和物理两个部分。逻辑部分由命名空间和类名组成。实际上，从公共语言运行库（CLR）角度而言，命名空间并非真实存在。我们假定命名空间在编程语言中存在，但从CLR角度观察，一个类名可能会包含一些点号。这就是类的逻辑名称。物理名称包括代码所在程序集的名称、版本号、区域信息以及此名称的密钥。

 

You can refer to a particular type in a particular assembly with a particular version or with a particular strong key. You can literally have a guarantee that you will either get precisely the implementation you were compiled against or nothing. Or, you can relax parts of the strong name. You can say, "I'll take any version later than some version."

你可以通过指定版本号或指定密钥来引用指定程序集中的指定类型。你可以（通过强名称）逐字地确保精确实现对某些东西是否编译。当然，你也可以弱化强名称的某些部分（的限制）。你能这样讲：“我可以使用比某个版本更低的任何版本”。

 

Enforcing Semantic Contracts

强化语义契约

 

Bruce Eckel: Have you come up with any interesting thoughts about ways to enforce semantic contracts?

对于如何强化语义契约，你有什么让大家感兴趣的看法？

 

Anders Hejlsberg: I think the most promising ideas are existing and new developments in pre- and post-conditions, assertions, invariants, and so forth. Microsoft research has several ongoing projects that we continually evaluate . We have looked at some pretty concrete proposals. In the end we realized that—as is the case for almost any truly important feature—you can't just do contract enforcement from purely a programming language perspective. You have to push it into the infrastructure, the CLR, the Common Language Specification, and therefore all the other programming languages. What good is putting invariants on an interface, if it is optional for the implementer of the interface to include the code of the invariant? So it's really more at a type system level than at a programming language level, but that doesn't necessarily mean that we're not going to address it. We are not doing that in the next release, but it could become a first class feature in C# down the line.

我认为大有希望的一些想法已经存在了，如前置条件（pre-conditions）、后置条件（post-conditions）、断言（assertions）和不变式（invariants）等思想的进步。我们陆续评估了微软研究院正在开展的一些项目，同时研究过一些相当具体的建议，最后认识到——对于任何一个真正重要的特性而言都是如此——你不能仅仅从编程语言的角度进行契约强化。你必须将它放入基础架构、公共语言运行库和公共语言规范（Common Language Specification），然后才轮到所有别的编程语言。如果实现接口时是否包含带有不变式的代码是可选的，那么将不变式置于接口上有什么好处呢？它是居于类型系统层次而不是编程语言层次的，但这并不意味着我们不将考虑它（译者注：指编程语言层次）。在下一个版本中我们还不会这样做，但是顺着这条路走下去，它终会成为C#中的基础性特性的。

 

Interoperability

协同工作能力

Bill Venners: You have said that where Java is striving for platform independence, .NET is striving for interoperability. What do you mean by interoperability?

你说过，Java为平台无关性努力，.NET为协同工作能力努力。什么是协同工作能力？

 

Anders Hejlsberg: Interoperability means several things. First, it means interoperability between various programming languages in .NET. Our design goal was that the .NET CLR would be language neutral, that it would support multiple programming languages. Java, by contrast, was one programming language and execution machinery for that one programming language. The CLR supports many features that have surfaced in only a few programming languages, for example, pointers. Unsafe code in C# and managed C++ have pointers, but Visual Basic and JScript don't. Yet all the infrastructure for pointers is in place in the CLR. Language interoperability is about the realization that as much as we try we're not going to convince everybody that you just program in one programming language. And honestly the way that the industry moves forward and innovation happens is by new programming languages being created. And we're not going to try to stop that. We're going to encourage it.

协同工作能力有几个方面的意思。首先，它指.NET框架下不同语言的协同工作能力。我们的设计目标是：.NET CLR成为语言的核心，让它支持多种编程语言。而相反地，Java只是一种编程语言，而且它提供的执行机制也只支持一种编程语言。CLR支持很多只有少数几种编程语言具有的特性，如指针。C#的不安全代码和托管C++有指针，但VB和JScript没有。然而，指针的所有基础性支持都放置在CLR中了。我们将努力实现多种语言的协同工作能力，而不是要人相信你仅仅使用一种语言编程。老实说，工业进步和革新出现都是伴随新兴编程语言的发明到来的。我们不但不会阻止，反而会推进这一进程。

 

Another aspect of interoperability is interoperability with existing systems. Back when we were in the Java business, one of the things that we tried to improve upon in our Java VM was interoperability with existing code, because we just think that kind of interoperability is so key. And we still think that. In the CLR, therefore, we have focused very heavily on interoperability with DLLs,COM, OLE automation—all of these technologies that any piece of code was written in before .NET.

其次，它是指已有系统间的协同工作能力。回头看Java模式，其目标之一就是努力提升Java虚拟机的能力，就是为了和已有代码协同工作，这恰恰是因为我们看到这种协同能力至关重要。顺此思路，在CLR中，我们就非常关心与DLLs、COM以及OLE的协同——使用这些技术的所有代码都是在.NET出现以前完成的。

 

It goes back to what I said earlier [In Part IV] that the key today is leverage. We've got to find ways for our programmers to leverage existing systems and code. Achieving that goal means having great interoperability, because how else can you leverage? That puts us in a complete opposition to Java's "100% Pure" viewpoint of the world. And I think we're doing the right thing with it. I really do.

我曾经说过（在第四次访谈）：目前，关键的是“杠杆”。我们要为程序员找到方法去“撬动”已有的系统和代码。实现该目标就意味着要有良好的协同工作能力，难道你有别的什么办法么？不过这也将我们推到了Java宣称的“100%纯度”观点的对立面，但我认为我们这样做是正确的，肯定是。

 

If you contrast what it feels like to call a DLL from C# versus to do it from Java, you'll very quickly see what I mean. It is very complicated to use JNI, and I think it is a pity that they haven't done anything better there, because so much more could be done. It doesn't make sense that the minute you have to interoperate with any other system in the world you enter this netherworld that is quite possibly more complicated than straight C or C++ programming. You have to run all these tools that spit out some header files. You have to remember to call this and that. If you want to dereference an object, you better remember to lock it down else it could, in one out of a thousand cases of running your program, move when the GC somehow happens to sweep right then. Then you can never reproduce it again. If it's OK for a system to do garbage collection and type safety and all, why shouldn't it help you interoperate? It just seems like such a reasonable thing to do.

如果你对比在C#和Java中对dll的调用方式就会很快明白我的意思。JNI使用起来非常复杂，我对他们没能做得更好些感到遗憾，实际上在这方面大有可为。此刻你就好像进入了地狱一样，它比用C或者C++直接编程要复杂得多，这毫无意义。你必须运行很多工具去挑出一些头文件，必须记住调用这个、调用那个。如果想解除对一个对象的引用，你最好首先锁定它，否则，此时垃圾收集器可能碰巧清除掉它——你的程序运行时，此种可能性为千分之一。如果这样的话，你就无法让它再生了。如果系统能够管理好垃圾收集、类型安全等等工作，岂不是对协同工作大有帮助么？这恰恰是一件非常值得去做的事情。

 

Bill Venners: From my perspective looking in from the outside of both Microsoft and Sun, I've noticed a cultural or philosophical difference between the two companies that I think influences the design differences between Java and .NET. At Microsoft, I get the sense that the prevailing view is that software is written to program the hardware—the box, the device, and so on. I think that's a totally reasonable perspective given how Microsoft makes its money. By contrast, even though "The network is the computer" was a Sun marketing slogan, I find that attitude really does exist in Sun culture to a great extent. The network offers the services, not the box. And Java is really like an object-oriented layer sitting on top of the network stack, aimed at abstracting away the heterogeneity connected to the network.

以我一个局外人的角度来审视Microsoft和Sun，我发现是两个公司在文化和哲学范畴的差异导致了Java和.NET在设计上的差异。我感觉，Microsoft的主流观点是：软件编写好后是用来控制硬件的，如一些匣子、设备等等。我认为这对于Microsoft为什么能大赚其钱是个完全合理的解释。而尽管“网络就是计算机”过去只是Sun的市场口号，但这种意识的确在其企业文化中有相当程度的积淀。网络提供服务，而不是“匣子”。Java的确像是一个居于网络栈顶的面向对象阶层，致力于剥离和网络相关的异质成分。

 

Anders Hejlsberg: What's interesting is that any Java solution you care to point at in the real world has platform-specific stuff in it. I know of nothing that is pure Java only, that doesn't somehow rely on some other component. Any of the web stuff relies on Apache or some web server, some database, and some form of interoperability with those systems. It's just ridiculous to think that the whole world is pure Java. The whole world is about putting systems together and making them work. And that's why the whole world is so excited about things like web services, because they're a wonderful way to interoperate. And we just think interoperability comes in many forms and we should just push as hard as we can and make it better and easier for systems to interoperate.

有趣的是，你在现实世界中挑出任何一个Java解决方案来分析，都会发现它包含与平台相关的东西。我还没有发现任何东西是纯Java的，一点儿都不依赖别的组件。Web程序依赖于Apache或者别的Web服务器，以及数据库，要和别的系统建立某些形式的协同工作关系。以为整个世界都是纯Java的，这非常荒谬。世界是把各种系统放到一起，然后让它们一起工作。这就是全世界都为Web Services这类东西感到激动的原因——它们是实现协同工作的美妙方法。我们认为协同工作能力将出现在很多领域，我们将竭力推动它的发展，让各种系统更好、更早地协同工作。

 

Bill Venners: Actually, the scenario you just described is exactly what I have on the Artima.com server. I have Tomcat running JSPs, and Tomcat does talk to Apache.

事实的确如此，你所描绘的就是我的Artima.com服务器工作时的情景。我用Tomcat来运行JSPs，让Tomcat和Apache对话。

 

Anders Hejlsberg: And you probably have a database.

可能你还有一个数据库。

 

Bill Venners: Yes, the Java application also talks to a database. There is platform-specific stuff in the sense that the Java API implementations use JNI, but the code of my application is all Java. And in my case even the connectors from Tomcat to Apache and the database are pure Java, because they use sockets to interoperate, not JNI.

是的，Java应用程序也和数据库通讯。在Java API通过使用JNI来实现这点上讲，是平台相关的，但我的应用程序代码都全是Java的。在我的这个解决方案中，甚至Tomcat与Apache、数据库的连接器都是纯Java编写的，因为它们使用套接字而不是JNI来协同工作。

 

Bruce Eckel: One of the things that I like about Python is that it says if you want to be platform independent you can, if you want to talk to the platform, you can.

我喜欢Python的原因之一就是它告诉我：如果你希望平台无关，你能办到；如果你想和平台对话，你能办到。

 

Anders Hejlsberg: Yes, exactly. It should be your choice.

完全正确，你的选择应该是这样。