I thought that Bill was going to post this as he was the one who pointed it out to me but I guess he was “busy” looking at the latest from Microsoft Marketing. Anyhow, in a nut shell the VB team have made a very questionable decision when it comes to Extension methods:
In this example I have a custom collection, say MyCollection and I also have an Extension method defined as DoFunkySutff(collection as MyCollection). How would this look in intellisense?
When I write instanceOfMyCollection. I would be prompted with a list of methods, including the extension method DoFunkyStuff() – Note that the collection argument is NOT listed as the compiler is doing the translation from instance to extension method by placing the instanceOfMyCollection as the first argument to the call to the static DoFunkyStuff method.
Ok, so what happens if I had a method defined on MyCollection which has the same name (and signature), ie DoFunkyStuff(). Well the intellisense experience is going to be the same – It’s going to be hard to distinguish between the two types of calls!
The story gets worse: What happens if this method has a different signature, eg DoFunkyStuff(i as integer). Here the C# and VB.NET stories diverge. In C# you would get both DoFunkyStuff(), the extension method, and DoFunkyStuff(i as integer) in the intellisense list. However, in VB.NET you will only get DoFunkyStuff(i as integer). Basically this is a result of VB.NET using shadowing by name v’s shadowing by name and signature (the correct way!!) which C# is using.
To make matters even worse (both languages): What happens if I have two imports that define the same extension methods for the same class – Compile error!!! And you can’t even use Aliasing to get around it. Clearly there is still work to be done to resolve these issues.