Comments on: Refactoring the .Net Framework

By: andar909

andar909 — Sun, 10 Aug 2008 23:54:55 +0000

hi, andar here, i just read your post. i like very much. agree to you, sir.

By: Greg Young

Greg Young — Sat, 26 Jul 2008 23:31:11 +0000

Just a thought as to why it hasn’t been changed … It can’t be “easily” changed in a service pack.

System.IO.File is a class that is covered by the ECMA specification for the BCL. There aren’t a ton of classes in the spec but it is one of them. A change to it would require an update to the spec which is not a trivial manner (I can only imagine the red tape surrounding that one).

Cheers,

Greg

By: David Starr

David Starr — Fri, 25 Jul 2008 07:02:06 +0000

Here’s an even more verbose discussion on it.
http://www.sellsbrothers.com/news/showTopic.aspx?ixTopic=411

One thing that recurs in the discussion is the idea that sealing within a framework product implies a lack of functionality in using the framework.

I may have to think on this one a bit more.

By: Matt Berther

Matt Berther — Fri, 25 Jul 2008 06:18:05 +0000

Hi David,

Often times the decision to seal a class is made with security or performance considerations in mind. The IHttpContext refactoring was probably not one of those and was just one that they got wrong. However, I could see some security challenges with unsealing classes like String or File.

http://codebetter.com/blogs/patricksmacchia/archive/2008/01/05/rambling-on-the-sealed-keyword.aspx

By: Jarod

Jarod — Fri, 25 Jul 2008 03:05:41 +0000

Hey Dave. I thought the IHttpContext the Asp.Net/MVC team was working with got moved to an abstract class HttpContextBase ~

http://haacked.com/archive/2008/02/21/versioning-issues-with-abstract-base-classes-and-interfaces.aspx

The one linked looks like its from IIS 7, is that right? Hmm.. confusing.

As for the sealed classes, you could always use Extension Methods. Though im sure you know that, and its not the point of the post…