Leggendo il libro LINQ in Action vinto ai Community Days 2008 (consegnato direttamente da Andrea) ho scoperto un comportamento degli Extension Methods che non conoscevo. Il quesito posto nel libro è: cosa succede se un Extension Method va in conflitto con un Instace Method? Semplicemente "perde la battaglia" in quanto un Extension Method ha una priorità più bassa. Riporto lo snippet e l'output presenti nel libro:
1: using System;
2:
3: namespace ExtensionMethods
4: {
5: class Class1
6: {
7: }
8: class Class2
9: {
10: public void Method1(string s)
11: {
12: Console.WriteLine("Class2.Method1");
13: }
14: }
15: class Class3
16: {
17: public void Method1(object o)
18: {
19: Console.WriteLine("Class3.Method1");
20: }
21: }
22: class Class4
23: {
24: public void Method1(int i)
25: {
26: Console.WriteLine("Class4.Method1");
27: }
28: }
29: static class Extension
30: {
31: static public void Method1(this object o, int i)
32: {
33: Console.WriteLine("Extension.Method1");
34: }
35: }
36: class Program
37: {
38: static void Main(string[] args)
39: {
40: new Class1().Method1(12);
41: new Class2().Method1(12);
42: new Class3().Method1(12);
43: new Class4().Method1(12);
44: }
45: }
46: }
1: Extension.Method1
2: Extension.Method1
3: Class3.Method1
4: Class4.Method1
Come dimostrato dallo snippet un Extension Method viene chiamato solo quando non esiste un Instace Method con la solita firma. In VB.NET per default non abbiamo il solito comportamento in quanto il compilatore se necessario effettua una conersione automatica dei tipi, quindi l'output sarà:
1: Extension.Method1
2: Class2.Method1
3: Class3.Method1
4: Class4.Method1
per evitare questo comportamento dobbiamo impostare Option Strict On, causando un errore di compilazione.