Why Are So Many of the Framework Classes Sealed? (2004)

blogs.msdn.microsoft.com

5 pointstosh3 comments

Yeah, Eric is wrong about this.

His argument boils down to, "If we let chefs have any knife they wanted, they'd choose the ones that cut most efficiently and proceed to cut themselves! We can't have that, now can we?"

In practice, it wasn't a huge problem, but there were times when getting around it was just a waste of my time.

I think the more important chunk of his argument was the downstream dependency; you now aren't testing your interfaces against all expected usage in the code you're writing, you're now building it against the expected usage of any and all arbitrary code now and in the future.

As well as, as soon as you unseal it, then you have to assume it's being used somewhere, and you're suddenly dealing with a much more exposed and expansive API to maintain.

What is this inheritance demand for subclasses to be signed by a key, and what language enables that?

Reply on news.ycombinator.com