Neil just pointed out to me this article from Scott Guthrie that talks about a new feature available in the "Orcas" release of the C# and VB.NET compiler called "Extension methods". The general idea is that you can "extend" a class without subclassing, even if it is sealed.

This looks like a very powerful feature and Scott does well in giving some nice examples demonstrating this, but I am very skeptical. Here are some of my concerns:

1. I have never felt the need to do anything like this. When I was using VB6 I felt the need to use inheritance because I would use it to solve problems and simplify my design. This feature does not help me simplify my design nor solve any problems. If I don't need something I consider it clatter and often it is an obstruction.
2. Implementation logic for a class can exist in more than one file, in different namespaces. This scares me. It is not the same as having inheritance and the inheriting class residing in a different namespace, because then it is actually a different class all together.
3. This feels an awful lot like multiple inheritance and we all know what a nightmare that is.
4. What kind of issues will this cause when using reflection? If I load an assembly, get the type of a class (i.e. GetType()) and then load an assembly that includes extension methods for that type, can I access these extension methods through the reference I have to the type already?
5. What if I want to use two assemblies in my application that both define an extension method for a type with the same name? If we all start using our own handy little helper methods such as the "object.In(IEnumerable)" that Scott demonstrated, how will you be able to combine two or more assemblies from 3rd parties?
6. People already mis-use inheritance, can you imagine what is going to happen with this?
7. Reading code you did not write will become a nightmare. This may not sound like a big deal, but in my opinion it is.
   1. Code reviews are vital in many methodologies, especially "agile" types ones. The process will become slower and more painful.
   2. Reviewing code is a very effective way of catching issues/bugs before hitting testing or investing a lot of time and effort in a design that will not work. People will start ignoring certain pieces of code such as "object.In(IEnumerable)" because although they have never seen this specific implementation before they will assume it works as they have seen it many times in the past.

Some will argue that partial classes present similar issues, but that's not true

1.  
   1. Partial classes cannot exist in separate namespaces and therefore cannot exist in separate assemblies.
   2. Partial classes were implemented to solve a specific problem, the partial auto-generation of a class. When used to solve this specific problem they are intuitive, easy to use, easy to understand and easy to maintain.

At the end of the day, the only real benefit of using "Extension methods" is making a line of code shorter. I don't know about you, but this

bool isInArray = "test".In(values);

is not that much shorter than this

bool isInArray = ArrayHelper.In("test", values);

[Updated 27.03.2007] Daniel's post has already answered some of the common questions on the subject, check it out if you haven't already.