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 Comments
archived from WordPress — closedI feel y'all miss Chris' point. all he is saying is whether it makes sense to derive or not is too limiting a decision to be made at the language level. whether it adds complexity to your code or not is a function of your programming style. you can cut vegetables with your kitchen knife or if you feel like it you can cut your toe. its upto you -- don't blame the knife.
Dilip,
Actually, that last sentence you point out is a double-edged sword: It can cut both ways.
Consider that same principle applied in the other direction: Don't blame sealed because it can be misused.