MyEnum enum1;

enum1 = enum1.FromString(thestring);

IMO that’s not natural at all.

Here’s your solution:

public static Enum FromString(this Enum theEnum, string fromString)
{
return (Enum)Enum.Parse(theEnum.GetType(), fromString);
}

Do like Oboma – “When I open my mouth, I like to know what I’m talking about.”

a[0][0] = Matrix.m11

Now, the Matrix struct is awesome and used in alot of places but the one thing that I can’t do with it is access the rows and columns by indexer like myMatrix[0][0]. I figured I could just make an extender like Matrix.SetValueByRowAndColumn(this Matrix m, int rowindex, int colindex, float value) or something but seeing that Matrix m is passed over byVal and not byRef, you can’t change any of the values!

And I NEED to write it this way, I have nested loops that run through the rows and columns of my matrix (from the ported code) that would be very sloppy if I broke them out.

So what was my simple solution? I just changed the “this” into a “ref” and now instead of an extender, I’ve got a static method that looks like:
MyNamespace.MyClass.SetValueByRowAndColumn(ref myMatrix, (int)row, (int)col, (float)val);

It’s not as pretty and completely defeats the purpose, but after reading through this page and all of the comments I was ready to shove my head in the oven. Figuring out that there was a simple fix made me ecstatic!

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.