Almost two years ago, to the day, I completely gave up on Silverlight. How do I remember the day so clearly? Because every now and I again, I get an email notification that someone has replied to my following forum post: http://silverlight.net/forums/p/1334/216456.aspx. In it, I asked why the Shape classes are sealed. At the time I figured it might have just been a early-release kinda thing. However, since the issue continues to be raised I’ll assume the problem still hasn’t been fixed.
This whole thing reminds me of another common .NET problem – internal framework classes. This was a hot topic with the release of .NET 3.5 and the ExpressionVisitor code, so much so that a David Kean from Microsoft jumped in to explain the situation. For the most part though, all it did was highlight how inefficient and unwilling to change Microsoft was. Why are classes internal? Because the process to make them public involves 20 some people and a multi-layered review system. There’s no “how do you guys handle these problems?” or “where can we improve” – merely a statement of fact of how things are (and therefore must be).
Back to the sealed silverlight classes. This to is a pretty old topic – remember Java is virtual by default, C# is not. What annoys me though, is the approach Microsoft has taken. I asked Why are the classes sealed, and the official response was Why do you want them unsealed? If .NET is built on the basis that developers need to justify how they use the framework, we’re in deep shit. The default behavior of a framework developer should be to open components, and only close them off when necessary. Otherwise it limits what your customers can do with your product, places assumptions on how your framework will be used, and makes it clear that you think you know better than we do. Lets not forget that coming up with a use-case for inheriting Line isn’t particularly difficult – maybe I want to create my own DottedLine class?
The specific wording used by Nick Kramer (Silverlight’s Program Manager) was:
“We want to err on the side of less API surface area — if you’re
missing something important someone will tell you, but if you include a
feature that doesn’t get used you’ll never hear about it, and will pay
the download cost for it forever. We weren’t able to think of a
compelling reason for arbitrary subclassing, but maybe we weren’t
creative enough — what scenarios do you have in mind?”
It isn’t Nick Kramer & Team’s job to think of reasons for subclassing (its our job to do that). Nick Kramer and Team should only be concerned with reasons not to have an unsealed class. Nick did provide some of that reasoning, but I’m unconvinced. Essentially coming down to performance and wrapping unmanaged objects – issues simple enough to cover via documentation.