See this blog from the VBTeam:
http://blogs.msdn.com/vbteam/archive/2007/01/24/extension-methods-and-late-binding-extension-methods-part-4.aspx

I always liked Maths better than literature in High School, so I guess that’s why I like C# better

Thanks for all your comments.

For me I prefer the readability and self documenting. If you have ever had to come back to something you wrote 10+ years ago and try to figure out what you did. You will greatly appreciate those features. Granted you can do a lot of that in C# too with a little extra effort, but it’s not as natural as in VB. VB reads more like English, while C# reads more like math to me. I use both, but I prefer VB for the vast majority of my projects.

Incidentally, the reason I describe it as a flaw in VB is because of what I read on the VB Team Blog (http://blogs.msdn.com/vbteam/archive/2007/01/05/extension-methods-part-2.aspx). Here they talk about making a design change while implementing extension methods in VB to bring the behavior at a parity with what it is in C#.

If there needs to be consistency in this approach, then allowing ByRef, which is something that is not possible to do in C# (even if you are using an extension method defined in a VB module), would break such a parity.

It’s not just a language thing. Imagine (for argument’s sake) how an API developed in VB.Net that makes use of extension methods would break if consumed from C# because it used a ByRef parameter.

There are differences in VB and C#, and most of them are style differences, but one like this doesn’t make sense at all. At their core, the languages are supposed to be the same, and it shouldn’t matter which one I develop in. But a difference like this can make it matter, right? (given my API example above).

Cheers.

@Chad… yes, I agree.

Likewise with x.SomeExtMethod() causing x to be a pointer/reference to totally different object is horrible for code clarity and solubility.

Magic pointers are bad and lead to instability and surprises in code. I’m not saying VB is bad, but I *AM* saying that magic pointers are bad. This problem existed in C/C++ and it was bad there too.

C# doesn’t have this bug for precisely the reasons I mentioned above.

Typical of a C# guy to think it’s a flaw in VB. Why can’t it be a flaw in C#? Which it is! C# programmers make mistakes too, even if they don’t think so.

Having learned many languages over my career, I always find the arrogance of C# guys funny.

Incidentally, here’s a new thing: If I have used ByRef in the VB Extension method, I still can’t use it from C#, because I get an error message saying “Argument one must be passed with the “ref” keyword”. And since I am calling this as an extension method, I can’t qualify the parameter

I think, it’s never meant to be ByRef, and it’s a VB flaw that allows it to be ByRef.

Cheers.

I ran into problems trying to test it, though, so let me give you a walkthrough of my successful test:

1) First, I created a VB.Net project in a scratch solution called “Extenders” with a default namespace of “Extenders”
2) Next, I created a module which I didn’t bother renaming “Module1″
3) Within that, I created a simple extension method that adds the phrase “Hello World!” to a string. Here is the full code:

Imports System.Runtime.CompilerServices

Public Module Module1
<Extension()> Public Function AddHello(ByVal val As String) As String
Return val + “Hello World!”
End Function
End Module

4) Finally, I created a simple C# application to call it, adding a reference to the Extenders project. Here’s the complete code:

using System;
using Extenders;
namespace ExtenderTest
{
public class TestExtender
{
public static string TestAddHello()
{
string test = “Test”;
return test.AddHello();
// returns “TestHello World!”
}
}
}

I mentioned trouble; the trouble was my natural C#-oriented inclination to add a namespace declaration to my code.

I had noticed that Visual Studio hadn’t added a namespace declaration to Module1.vb when I had created it, so I had inserted it myself, like this:

Imports System.Runtime.CompilerServices

Namespace Extenders
Public Module Module1
<Extension()> Public Function AddHello(ByVal val As String) As String
Return val + “Hello World!”
End Function
End Module
End Namespace

My test code (as shown in step 4 above) failed to compile. After confirming that I *should* be able to do it via google, I started messing around, and eventually got my C# code to compile as follows:

using System;
using Extenders.Extenders; // <– the difference is here!
namespace ExtenderTest
{
public class TestExtender
{
public static string TestAddHello()
{
string test = “Test”;
return test.AddHello();
// returns “TestHello World!”
}
}
}

I pointed out the difference with a comment, since it’s a little subtle. It turns out that VB implicitly adds the default namespace specified in the project properties to any namespace declarations in code. Freaky, that — I’m too used to explicit declarations. Now, I don’t know if that’s the problem you ran into, but I have verified that once you get the namespace using statement correct, the extension methods do, in fact, attach to the proper types.

It’s not enough for me to overcome the nasty VB syntax, though.

That VB importation thing worries me, though. VB extension methods should work in C#. Let me go test that and get back to you.

Let me put it this way. Enums aside, I can’t pass any type by Refernce in an extension method in C#, while in Vb.Net I can. So, while I agree with all of you that maybe an enum is not the best example of demonstrating this and my original goal was probably not the best of ideas (my defense aside), the main point is the significant difference in the two languages when it comes to extension methods.

That is my only point of contention. Actually, it’s not the only one. There is one more thing that I tried which left me even more exasperated (and I mention it at the end of my post). When I declared extension methods in a VB class library project, and imported it in a C# application, the extension methods did not attach to their types. I had to call them explicitly (ModuleName.MethodName(type_extended)).

While if I do the opposite (extension methods created in # and imported in VB) they work as expected.

Well, life’s tough I guess

Although yes, VB can do something C# can’t (it does occasionally happen! ), in this particular case I would argue along with the others that you shouldn’t do things the way you initialy wanted to do them.

Enumerations are designed to be read-only value types, similar to integers (which they are, under the covers), booleans, and floats. Extension methods to enumerations should follow that paradigm — they should not modify the underlying value, they should return a new, updated value. Although you would always know that the method operates on the instance itself, the average person maintaining your code would expect different execution.

I would argue that the method you linked to in your first reply is the best method of parsing an enumeration, even though it extends string rather than Enums. It has problems though; you cannot constrain a generic method against the type Enum. I don’t quite know *why* you can’t do it, but the C# compiler balks with “Constraint cannot be special class ‘System.Enum’” for some reason. That means the linked method has to check the type and throw an ArgumentException, and that just doesn’t make sense, in my opinion. I mean, is the generic type actually an argument to the method call?