I had dinner with the BCL (Base Class Library) Team on Tuesday. Among those in attendance were Brad Abrams, Kit George, Joe Duffy and other framework developers. The ratio of Microsoft employees to non-Microsoft people was about 2:1.
I voiced a few concerns of mine:
Open API Specs.
I argued that Microsoft should release internal APIs specifications, because the MSDN documentation is poor. Although internal specs tend to be out-of-date and available only in English, they do provide more of the backstory of the API, that you typically find only in blogs or the few articles that appear on MSDN Magazine. MSDN documentation are written by the User Education group, who serve the needs of multiple products and are essentially out of the loop, while the specs are written by the same program managers who originate the features and work in close collaboration with testers and developers.
Releasing the specs may be less important for the BCL than for other groups, since sources are already available from Rotor; on the other hand, the BCL and CLR play a central part of every managed program.
My issues in past have been with GDI+ and System.Drawing, which is heavily underdocumented, and to a lesser extent, Windows Forms. Since System.Drawing wraps the unmanaged flat GDI+ API, the API is essential opaque. For example, it took me a while to learn how to overcome the limitations of GDI text rendering, that make it nearly unsuitable for developing a wordprocessor-like application. Microsoft had to issue a KB article that recommends either using GDI text support or enabling anti-aliasing, which produces blurry text for small font sizes, to overcome those limitations. Another example is the Save and BeginContainer methods in Graphics class, which perform very differently, yet have the same MSDN documentation that fails to differentiate between the two calls. Another example is the hoops that a number of smart developers had to go through to reverse engineer the Windows Forms designer and to create a new Designer surface.
The CLR does not provide support for weak delegates, which leads to one of the most common sources of memory leaks in the framework. For example, the NumericUpDown control leaked memory because it failed to release an Application.Idle call after it was disposed. For my own projects, I have used weak interfaces in lieu of delegates.
I have seen two experts, a CLR developer, Joe Duffy, and a .NET author, Ian Griffiths, both screw up their implementations of weak delegates and in the exact same manner. What they both did was to create a weak reference that points to the delegate (rather than the target object of that delegate). Unless a reference to the delegate is saved elsewhere, the very next garbage collection will blow away the weak reference to the delegate regardless of whether the target of the delegate is reachable.
My other issue with delegates was the inability to change the target of a delegate. One could do this with reflection by calling MethodInfo.Invoke, but that is a couple orders of magnitude slower than it should be. Whidbey does provide a workaround with Lightweight Code Generation.
I requested support for weak collections, one of which includes a dictionary with a weak key. In this case, one cannot simply pass a weak reference as a key. Since I already have my own implementation, it wasn’t urgent for me.
I mentioned multiple dispatch methods—a kind of dynamic overloading. This is valuable for implementing the Visitor Pattern, a very powerful design pattern. I was surprised that people in the BCL were not well-versed in Design Patterns.
I also inquired about support for dynamic properties, which would allow some fields to be maintained in a dictionary to alleviate concerns with large number of fields or events.
I wish that I had brought up the ability to define methods within enumeration classes or to provide default implementations for interfaces.
I had a lot of radical ideas that I didn’t mention, mostly involving features from various academic languages that unlikely to come in the next few years. I firmly believe that the new advances in languages will borrow heavily from languages invented three decades ago such as Lisp and Smalltalk. Already, we have seen the advent of garbage collection, closures and iterators in C#. Languages will also become more declarative over time. (According to Alan Kay, computer professionals were smarter back then, because computing was still an esoteric technology. Now, we have a pop culture when colleges are essentially vocational schools for Java.)