D Melodic Minor Accidental : Random .NET Platform

"Find All References" Design, regarding interface members

TheoY — Thu, 07 Jul 2005 01:42:00 GMT

One of the things that I've been working on to help finish Whidbey, are the new refactoring features. However, I've recently found myself questioning the design for "Find All References", in regards to its handling of interface members. I discovered this behavior while writing a toy project in C#, but the following example illustrates it better, in my opinion. Imagine you're writing a generalized library - and provide two different interfaces, IResource and IStream. Both of them have the notion of a Close() method (for simplicity sake, I'll put the interfaces in separate files, which will help make it easier to see the design confusion):

namespace Library {

public interface IResource {

void Close();

}

namespace Library {

public interface IStream {

void Close();

}

Simple enough, right? The conundrum arises when you have an object that implements both interfaces, and uses the the same member to implement them, such as the following:

using Library;

class NetworkSocket : IResource, IStream {

public void Close() {

}

What struck me as awkward, is that if you then do "Find All References", on IStream.Close(), you'll get the following results:

(Definition) NetworkSocket.cs - (5,17): public void Close() {
(Definition) IResource.cs - (5, 14): void Close();
(Definition) IStream.cs - (5, 14): void Close();

Thus, intellisense reports that IStream.Close() is defined in all of those three places. However, why is IResource.Close() in this list? Some IDE-team members argue that the design was that we would return the transitive closure of all of the methods that are captured during this find process. I, however, argue that this is definitely unintuitive. This gets worse too, for example, introduce the following:

using Library;

class OtherResource : IResource {

public void Close() {

}

using Library;

class OtherStream : IStream {

public void Close() {

}

using Library;

class StreamReader {

public StreamReader(OtherStream stream) {

// ...read the stream ...

stream.Close();

}

Now, invoke "Find All References" on IResource.Close(). You'll get the following results:

(Definition) NetworkSocket.cs - (5,17): public void Close() {
(Definition) OtherResource.cs - (5,17): public void Close() {
(Definition) OtherStream.cs - (5,17): public void Close() {
(Reference) StreamReader.cs - (6, 16) : stream.Close();
(Definition) IResource.cs - (5, 14): void Close();
(Definition) IStream.cs - (5, 14): void Close();

IStream.Close() is on the list (which is the reverse case of the previous "strange" element), but what really makes me think this is wrong, is that StreamReader's use of OtherStream is there. OtherStream doesn't even implement IResource, so it's impossible for OtherStream.Close() to be related to IResource.Close(). In that context, you *know* you're not dealing with an IResource, however, it's still a reference <shrug>. This gets worse as you have more types that implement IResource or IStream, because whenever you do Find All References on Close(), you get even more unexpected results to wade through.

So, you wonder, is there any method behind the madness? It's all about Rename refactoring. If you rename IStream.Close() to something else, you better rename IResource.Close() to the same thing, otherwise the NetworkSocket class will suddenly no longer implement all the members of IResource. I think that's a valid concern, but IMHO, if you're sharing implementations on the same member, and then you rename one of the interfaces's declaration of that member, then I would expect a compiler error to be introduced, saying that you can no longer implement both interfaces with the same member now. Just because one developer happens to implement my interface, and someone else's interface, doesn't mean that if someone else renames their interface member that I too should be renamed.

So, mine is obviously a directed perspective, but how do the rest of you out there feel about this?

Referring to "value types" versus "reference types", Part 2

TheoY — Tue, 28 Jun 2005 23:31:08 GMT

Last Friday, I blogged about confusion between the terms "value" and "reference", when relating to .NET development. The post can be found here:

http://blogs.msdn.com/theoy/archive/2005/06/24/ValueRef.aspx

This time, I'm continuing the discussion specifically relating to value types and reference types. After this, passing by value / passing by reference will be covered, as well as referring to an object's "value" or its "reference". So, continuing... I left off stating that I still have the following topics to cover, as part of Referring to "value types" versus "reference types":

   (1) Enums
   (2) Type unification, boxing/unboxing
   (3) Interfaces and inheritance for value types

Enums

.NET has built-in support for a special kind of type, called an enum type. Enums are also value types, and have all of the traits that I described for value types in the previous blog entry, except for some small differences that are not relevant to this topic. One way to look at them is as specialized value types. For example, .NET enum types don't have instance fields, nor methods or properties. Basically they exist so that one can specify names for what would otherwise be numeric values. Their syntax is as follows:

    C#/J#:
        enum MyEnumType {
        }

    VB.NET (requires all enum types define at least one value):
        Enum MyEnumType
            OneSampleValue
        End Enum

Each of the languages will automatically assign values to the enums if you don't care, but also will let you define specific values to assign to their corresponding names if you wish. As you'd expect, they all compile down to the same thing under the hood, which is one of the reasons why .NET language integration is so streamlined between C#/VB/J#. However, when contrasting value types and reference types, a user only needs to know that enums are in the "value types" camp.

Type Unification, Boxing and Unboxing

This is when it gets a little hairy... so in the first article, I described value types getting allocated on the stack, and reference types on the heap. However, there are some leftover questions that you're probably pondering, such as:

(1) If anything that doesn't extend from System.ValueType is a reference type, then how does the CLR tell the difference between value types and the rest of the types that descend directly/indirectly from System.Object?
(2) How do value types implement interfaces, and how are those interface implementations distinguished between those of reference types?
(3) Is System.ValueType itself, a value type or a reference type?

Those are all good questions, and require understanding of the CLR type unification system. Java has less of this to worry over, since it doesn't support custom value types (it only supports its built-in "primitive types"). In fact, prior to Java 1.5/5.0, users had to explicitly convert their primitive types to their corresponding wrapper objects (e.g. java.lang.Integer). In addition, users of reflection on Java would have to deal with two different class objects for each primitive and its corresponding wrapped type. Not fun.

Thus for .NET, there came a need to unify this more - and they introduced a concept of boxing and unboxing. You can think of boxing and unboxing as being another special form of copying, for a value type (in fact, one must realize that boxing and unboxing performs copies). However, the distinction between boxing and unboxing from other forms of copying (say assignment, parameter passing or receiving return value) is that boxing places a value type inside a wrapper (a "box") where it *then* behaves like a heap object. By wrapping value types as heap objects, they can then be treated the same way as other heap objects. .NET has built-in support for object-oriented type systems - and likewise has to implement virtual methods similar to pre-.NET C++, and Java. You probably guessed that virtual methods require some sort of special handling, that makes them different from non-virtual methods. Since any subclass an override a non-sealed virtual method, there needs to be some infrastructure to look up which function to actually run.

The way that those usually work is that an object in memory usually has a pointer (just an address value to some other chunk of memory) that points back to a shared virtual method table (or v-table), since in .NET and Java, overriding a method overrides it for all instances of that type. Then the object can be passed around as any super type that it implements, and when a function call is required, a lookup of the appropriate index in the v-table will allow for code to pick up the overriden method. As long as the means to access the v-table pointer are consistent, and the indices are consistent, then a function for one type need not worry about if it is executing on object that's actually an instance of a subclass.

This is all fine and dandy, but once you're passing around pointers to objects, and you're trying to avoid examining what type they really are, then how do you know if you're dealing with an implementation derived from a value type, or a reference type? The answer is, by default, you don't. That's why value types need to be boxable into heap objects, so that code that consumes any interfaces that they implement may be able to dispatch off of those objects without having to concern themselves on whether or not that object is a value type or reference type. Thus, it makes things easier to realize that when dealing with objects at an interface type-level, you're always dealing with heap objects - either reference type objects, or boxed value type objects.

The reason why I discuss "unification" is that in .NET, this wrapped value type support is automatically generated for you whenever you define a new value type. It would be a nightmare if each user had to define their own heap wrapper type for every new value type they defined. That's why Java's explicit type wrappers aren't a scalable solution if they were to allow users to define their own primitives. Also, when using reflection, boxed and unboxed value types share the same type object (e.g. if you use C#'s typeof() keyword). This means that if you're dealing with boxed or unboxed objects using reflection, you can confidently know that testing them against a type object will do what you'd expect (another issue with Java's having two separate class objects for wrapped and unwrapped primitives).

The last tricky part is that the type, System.ValueType itself, is not a value type. Users can only create objects of types that derive from System.ValueType, and using a value type as an instance of System.ValueType causes it to be boxed. The reason why is that once you're dealing with a value type at the System.ValueType level, you have very little knowledge remaining about the value type (for example, you have no idea what fields it has). All you have are virtual methods that you can call, which require boxing, as you'd expect. The same thing applies to System.Enum - once you're dealing with an enum value at the System.Enum level, you're actually dealing with a boxed enum.

As you can tell, System.ValueType and System.Enum have to be special-cased in the runtime, as their descendents are all value types. In my opinion, there's not really a great way to structure them in the inheritance tree, but here's how they're structured in reality: (go, go, ascii art)

   System.Object
      |
      +- System.ValueType
      |   |
      |   +- System.Enum
      |   |   |
      |   |   +- <all enum-types>
      |   |
      |   +- <all-non-enum-value-types>
      |
      +- <all-other-reference-types>

I use VS 2005 (Beta2 is pretty stable) when I code, and one of the things that I always change first is the fonts and colors preferences. I set VS to colorize all enums and value types in navy, instead of teal, so that I can notice what my code is doing, and whether or not I'm going to copy, box, or unbox. As you can see, I've actually colorized the types System.ValueType and System.Enum in teal, because those types specifically, are actually reference types. It's their derived types that are value types.

Interface inheritance for Value types

Users defining their own value types will notice that they can specify interfaces for their value types to implement. Yes, this is a powerful corollary to the unification described previously. When transferred to a context that requires an interface to be implemented, value types get boxed, and are then indistinguishable from reference types, to the interface consumers. What I mean by indistinguishable is that consumers needn't worry if they're dealing with value types or reference types - but they can of course query if the object in question also extends from System.ValueType (e.g. in C#, using the "is"/"as" keyword).

I think that pretty well summarizes most of the important differences between value types and reference types. In the queue of topics to cover in my future blog posts will be some best-practices for value types.

Comparing C# and VB.NET

TheoY — Mon, 20 Jun 2005 23:05:00 GMT

A reader wrote me just now:

Hi,

I just came across your blog and seeing that you're mentioning random thoughs on .NET, I was hoping you'd be able to answer this question: Is there any real difference to coding in VB or in C# when it comes to the .NET framework? If there are differences, do they still exist when I narrow the topic down to .NET web applications?

Thanks,
Max

When it comes down to it, in my opinion, there aren't many significant language differences between VB.NET and C#. Most of the constructs in those languages are achievable from the other language, which is why you'll often see samples online in both languages. I think VB.NET includes more implicit conversion operators, as well as a bunch of other constructs if you disable option-strict compiling (such as late-binding). C#, as a language, will generally be more explicit than VB.

With VS 2005 (C# 2.0), C# includes anonymous methods, which are not a VB construct - VB users can workaround it by declaring new types/methods as necessary (which is what the C# compiler does under the hood). C# 2.0 also supports new iterator methods (using the yield keyword), which I think is unsupported by VB.

VB includes a ton of "built-in" functions, which usually delegate to other .NET framework library functions that are accessible by C#. Because of that, VB programs load several .NET framework DLL's that are not always needed in all programs, but are required for supporting VB built-in functions. In C#, a lot of what the language does to supplement the .NET Framework isn't providing specific built-in functions per se, but more language features, that affect the way your code is compiled (instead of introducing other dependencies).

In regards to ASP.NET and web applications, I don't think that the above discussion applies any differently - the ASP.NET integration should be nearly identical for both languages. Any preference towards choosing VB over C# or vice versa will probably be off of developer's taste.

I'm sure other folks out there will point out other important differences between C# and VB, but these are the ones that come to mind.

.NET Framework SP's Available!

TheoY — Tue, 31 Aug 2004 00:00:00 GMT

For those who haven't gotten their hands on an Windows XPSP2 CD, new .NET Framework SP's are now available, for versions 1.0 and 1.1 (the first version of 2.0, or "Whidbey" is still yet to be released).

Here are the links to Microsoft's download center, the related "Knowledge Base" links may not become active on the web for a couple hours. When they become active, you'll be able to see a list of fixes included in these service packs. Rest assured, these patches are a culmination of a ton of work (by the .NET Framework team, and my team). In a couple of days, they should also become available via Windows Update.

.NET Framework Version 1.1
Service Pack 1 for All OS's other than Windows Server 2003
Service Pack 1 for Windows Server 2003

.NET Framework Version 1.0
Service Pack 3 for All OS's other than XP for Tablet PC / Media Center

Notice there are two links for the 1.1 version: it's because the .NET Framework is installed via Windows Installer technology on most operating systems, but is incorporated as an OS component for Windows Server 2003.

Likewise, 1.0 .NET Framework was incorporated as part of the XP version for Tablet PC / Media Center. So those users will actually get SP3 for the 1.0 .NET Framework by simply installing XPSP2.

If you're running Windows Server 2003, you should reboot after installing the 1.1 Framework SP in case some files (e.g. DLL's in the CLR and base class libraries) were in use during installation. The patch on Windows Update will always ask for reboot for the 1.1 SP1 patch.