Advertisement

Assemblies and Internal Access

Bill Venners: Could give a bit of an overview of how assemblies work, in particular with respect to the internal access level? The first release of Java included several com.sun packages that you weren't supposed to use directly. Sun didn't promise that in future releases of Java, the com.sun packages would be backwards compatible, but you could use them at your own risk if you just called into them. Java has several access levels, but there's no notion of a package that's private, accessible only inside its own JAR file. Anybody can see any package. I believe a .NET assembly kind of corresponds to a Java JAR file, and a .NET namespace corresponds to a Java package. Does the internal scope mean only accessible inside the assembly? Can an internal access level be applied to an entire namespace?

Eric Gunnerson: Well, namespaces don't control availability. I would explain it this way: a namespace is a convenient way of giving a class a long name. So if I have a namespace Utility and I have in it my class Multiplier, it really means that the class is named, Utility.Multiplier at the runtime level. So namespaces really aren't their own separate abstraction. Namespaces are ways of organizing the classes in a way that makes sense to programmers. Assemblies are related, but they're about organizing classes in a way that makes sense for deployment purposes. The organization you do for deployment is often analogous to what you do on the programming side, but often somewhat different.

I'll give you an example. We have a namespace System.Text for classes that do text handling. Because the functionality in there is used all the time System.Text lives in our main system assembly. But there's also System.Text.RegularExpressions, which has the regex engine. That lives in its own assembly. You don't want to require everyone to load the regex engine in all the time, because a lot of programs don't use it. So that's the kind of organizational decision that you might make differently while programming versus at deployment time.

As far as accessibility goes, we have public, private, and protected, which do what you expect, and we have internal. From the C# compiler perspective, internal really means scoped to everything that compiles together. Everything that compiles together really means everything that's in an assembly, because you take a bunch of files and compile them to produce an assembly. With internal scope, I can have classes within the assembly that kind of cooperate with each other, but people from the outside can't get access at that level. We don't have friends the way C++ has friends, and there are actually times when having friends would be very nice.