It’s not just the addition only nature of extension methods that makes them safe, it’s the fact that they are simply a regular static method once compiled. You can certainly make your code very confusing by overusing them (which I have done) but you won’t cause problems for anyone else.
Sometimes being able to modify a standard method easily would be helpful, but with all the trouble that can cause it’s probably best that the solution is something that is obviously an ugly hack. Some things shouldn’t be easy.
For those with short memories; what M$ tried to do to java (and caused Sun to sue) amounted to monkeypatching. In the java/M$ case, it was done to destroy Sun’s control of java. Caveat Emptor
most monkeypatching done is made out of sheer demonstration that they know metaprogramming (especially for ruby). i find it less smart to instantly resolve to monkeypatching the language itself rather than extending it within the application or its library.
most importantly, monkeypatching without documenting it is pure evil. it makes it harder to debug the application imho.
you can check for a null string and an empty string with String.IsNullOrEmpty. Saw this in some code somewhere and wondered how much time i had wasted typing s == null || s ==
Good post. To me, Monkey Patching seems like, if you’re having to do it, there’s some other issue which you’re having to work around which needs attention. Say there’s a function in the language which is actually broken: maybe a Monkey Patch would work but it would also warrant investigating if there’s a bug fix on the way and putting a reminder to remove the patch when it comes through. The problem I’ve always found is, though it seems easy to remove any sort of patching like this now, given time, anything becomes harder to roll back.
Since you’re extending the methods of a class to make it more usable, may I suggest choosing more usable method names?
Maybe it’s just because I’ve been spared this convention, but Left means nothing to me. I had to read your code just to figure out what it was expected to do.
In the Objective C Cocoa framework, we have a couple methods to accomplish what your Left and Right would. They’re called substringFromIndex and substringToIndex. Judging from your use of a built-in Substring() … it sounds like these better-named enhancements would also be at home in your C# project.
Here’s something that will blow your mind if you think monkeypatching classes is weird enough - in Ruby, I can monkey patch individual instances of a class:
class Foo
def bar
puts Baz
end
end
irb(main):012:0 a = Foo.new; b = Foo.new
= #Foo:0x5a18ec
irb(main):013:0 a.bar
Baz
= nil
irb(main):014:0 def a.bar
irb(main):015:1 puts Bamf
irb(main):016:1 end
= nil
Why not just add a reference to Microsoft.VisualBasic (which is included in the .NET Framework) and then use Left() function?
You can use Left, Right, Mid, etc. in C# by just adding a reference to that library that is already included in the Framework. It’s a not VB.NET specific library and it is included in all Frameworks.
The real problem with Left() (ie. the lack thereof) is that the substring function COMPLETELY UNNECESSARILY throws an exception if you pass a second argument longer than the string itself. WHY? (I guess the answer is arrogance amongst the original language devs, who came from a C background, and therefore did the right thing rather than the useful thing, when VB would always have done the later!)
