Our favorite all around geek rants this week on the use of sealed.

Sorry, Chris, but I beg to differ. I consider sealing a powerful abstraction. Sure, it limits the possibility of using extension by derivation, but so what? In many cases, it doesn't make much sense to derive at all. In others, it might add such complexity as to make it impractical (or at least too costly). And if I'm writing the code, then I may not want to allow it. So what?

Sure, it's easy to complain when you're not the one testing and supporting the extra complexity, but what the hell :) [1]

However, what really struck me hard was Chris' comment that "The C++ community survived very nicely without sealed for a decade...". Are you serious? That's a really crappy argument. The C++ community has lived for a decade without the concept of proper language-defined interfaces, a decent way to define abstract base classes, and a half-assed way to make things internal to modules [2]. Would you do away with interface, abstract and internal accessibility, too?

[1] OK, granted, I'll agree with you it is a feature that can easily be misused, and that the .NET framework designers may have been a bit too keen on its usage.
[2] OK, so this one is not exactly the same. And for those that didn't quite get it, I'm talking about unnamed namespaces and internal linkage.


Tomas Restrepo

Software developer located in Colombia. Sr. PFE at Microsoft.