The Artima Developer Community
Sponsored Link

Contracts and Interoperability
A Conversation with Anders Hejlsberg, Part V
by Bill Venners with Bruce Eckel
November 3, 2003

<<  Page 2 of 3  >>

Advertisement

Strong Names in .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.

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.

<<  Page 2 of 3  >>


Sponsored Links



Google
  Web Artima.com   
Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us