Virtual Static

In Smalltalk a Class is a first level object just like everything else in the system. Objects get instantiated using the Class as a template but the Class itself can have its own properties and methods. In fact constructors are just class methods in Smalltalk that return an instance.

Now as a C# programmer I've always thought of static properties and methods as the same thing as Smalltalk's class properties and methods. In the back of my head I knew that C# didn't have first-level Class objects but the static paradigm seemed to fit. So when the other day I wanted to override a static method in a subclass I figured no problem just mark the one in the superclass 'virtual' and then add my new implementation. One problem was that compiler balked at 'virtual static'.

After some searching around I found this blog post explaining why this was not a valid combination of keywords. As Eric Libbert writes:

Related questions come up frequently, in various forms. Usually people phrase it by asking me why C# does not support “virtual static” methods. I am always at a loss to understand what they could possibly mean, since “virtual” and “static” are opposites! “virtual” means “determine the method to be called based on run time type information”, and “static” means “determine the method to be called solely based on compile time static analysis”.

Turns out 'static' is really not equal to 'class'. I must admit I almost shed a tear that day as this sunk in.

Fluent Smalltalk

The other week I wrote about creating HTML controls in ASP.NET MVC using the Fluent Interface pattern. I haven't been a Smalltalker since the 90s so it took awhile for it click where I had seen this pattern before. In Smalltalk the default return value from a message send (aka method) is the receiver (aka the object itself or 'self'). You are encouraged by the language to create readable chains of method sends.

I also had a thought about how the C# compiler could support this as a language level feature by allowing the 'this' keyword as the return type for a method.

So instead of having to write a method like:

public Image ImagePath(string path) {
  imagePath = path;
  return this;
}

You could just write:

public this ImagePath(string path) {
  imagePath = path;
}

Smalltalk Extensions

In a previous lifetime I worked for a Smalltalk vendor and my last two posts (here and here) got me thinking about all of the ways that you could hack the Smalltalk environment. In Smalltalk, except for a few primitives, all of the base libraries source code is present and editable in your environment. You can edit the default implementations or easily add additional functionality to base classes. This can lead to all sorts of interesting side effects.

I remember working with one customer that had occasional lock-ups in their development environment which they were blaming on us. These lock-ups were intermittent and hard to reproduce. Well one day while in their environment I was able debug right after a lock-up. I started stepping through some code in the base collection class that I didn't recognize. Turns out they had overridden the inherited Sort function and implemented their own (might have been a quicksort I can't remember) along with a very subtle bug. Given the right list size and starting conditions the code would enter an infinite loop. Fixing their sort function fixed their lock-ups and contributed to my reluctance to ever touch base libraries.