Amigo mío Siempre estas Programando en .NET

¿Puedo?

La 3. ;-)

Y con tu permiso, te complico un poco el ejemplo:

   class Program

   {

       static void Main(string[] args)

       {

           new Foo().Bar((int)10);

           Console.ReadLine();

       }

   }

   class Foo

   {

       public void Bar(long l) { Console.WriteLine("Foo::Bar"); }

   }

   static class FooExtensions

   {

       public static void Bar(this Foo foo, int i) { Console.WriteLine("FooExtensions::Bar"); }

   }

Qué se imprime AHORA? ¿Foo::Bar o FooExtensions::Bar?

Saludos! ;-)

pd: Me encantan esos posts!

Creo que a la pregunta de Luis la respuesta es "Hello Foo!", y a la Tomas es "Foo::Bar".

Esto es porque una extensión no es más que un "caramelo" de compilación. En el momento que se compila una llamada a una extensión, se realiza usando el formato estático de la misma. Es decir, una llamada tipo: "foo.ExtensionMethod();", se traduce en tiempo de compilación como "Extensions.ExtensionMethod(foo);".

Pero esta "transformación" se hace si no existe el método en la clase original. Al existir, siempre coge el método de la clase.

De esto deducimos que no se puede sobrecargar un método desde una extensión.

¿He acertado? :)

>Pero esta "transformación" se hace si no existe el método en la clase original. Al existir, siempre coge el método de la clase.

Oui ;-)

Pero la sentencia correcta seria que la transformación no se hace "si existe un método en la clase original que pueda ser llamado. Es decir cuyos parámetros sean compatibles con los que se pasen, incluyendo cualquier conversión implícita que sea necesario".

Es importante este último punto: si NO hay conversión implícita válida, el método de instancia es descartado ya que no es "válido para ser llamado".

En mi ejemplo hay una conversión implicita de int (el tipo de parámetro, que he casteado para añadir "redundancia") y long que es el tipo del método de instancia". Por lo tanto el método de instancia se selecciona y el de extensión se descarta.

>De esto deducimos que no se puede sobrecargar un método desde una extensión.

Falso.

Si puedes, siempre y cuando la sobrecarga no entre en conflicto (incluyendo conversiones implícitas) con cualquier método de instancia definido:

   class Program

   {

       static void Main(string[] args)

       {

           new Foo().Bar("ufo");

           Console.ReadLine();

       }

   }

   class Foo

   {

       public  void Bar(long l) { Console.WriteLine("Foo::Bar"); }

   }

   static class FooExtensions

   {

       public static void Bar(this Foo foo, string s) { Console.WriteLine("FooExtensions::Bar"); }

   }

En este caso se llama al método de extensión, ya que no hay conversión implícita válida de int a string.

Saludos! ;-)

pd: Luis, eres responsable DIRECTO de mi baja productividad hoy :P ^_^

Y me corrijo, se puede sobrecargar de varias formas:

1. usando diferente número de parámetros

2. usando tipos de variable que no tengan un "cast" implícito. Por ejemplo:

  static class FooExtensions

  {

      public static void Bar(this Foo foo, string i) { Console.WriteLine("FooExtensions::Bar"); }

  }

  // ...

  foo.Bar(10.ToString());

Como un string implícitamente no se puede convertir en int, llamaría a la extensión.

Ahora yo tengo OTRA pregunta que hacerle a Luis...

Cuanto tiempo has perdido depurando hasta darte cuenta de lo que ha ocurrido y escribir este post? :P :P :P

Un abrazo!

pd: ¿Usáis mucho los métodos de extensión? ¿En qué situaciones? ¿Cuando decidís que algo es un método de extensión y no un método de instancia?

Realmente instructivo para ver el comportamiento de los métodos de extensión. Sería interesante ver cuáles son las buenas prácticas en cuanto métodos de extensión, para darles un uso adecuado y no abusar de ellos.

En mi caso, los he utilizado en una capa DAL para extender el IDataReader, para facilitar la recuperación de valores.

Saludos.

¿Qué sucedería si el cast es explícito? jeje

Nosotros usamos los métodos extensores en 3 casos:

1.- Cuando quieres añadir un método a una clase de la que no tienes control. Por ejemplo: string.Pascalize.

2.- Para evitar referencias cruzadas entre dos dlls. Por ejemplo, si una clase de una dll utiliza algunos métodos de otra dll y un método necesita la referencia cruzada.

3.- Cuando tenemos algunas clases auxiliares comunes (añadiendo el mismo fichero a dos proyectos utilizando añadir como link) entre la parte servidora (.Net) y Silverlight. No todas las librerias son iguales entre estos dos entornos y por tanto necesitas en algunos casos concretar el entorno. Por ejemplo: El método string.Compare no tiene los mismos tipos de argumentos y por tanto el código para llamar a este método debe ser diferente. PD: Esto tb se puede hacer con partials.

y un tercero, aunque no es muy 'elegante':

4.- Añadir código a una interface. Se puede hacer un método extensor a una interface y por tanto hacer una pseudo herencia múltiple en .net