Más sobre los parámetros opcionales y nombrados

Comentaba mi buen amigo Luis en respuesta a un post anterior que, a pesar de todo, no le gusta la idea de los parámetros opcionales. Como ya la conversación se estaba haciendo demasiado extensa, he preferido iniciar una nueva aquí.


Indudablemente, las razones que tiene Luis son válidas. Entre ellas muy probablemente estarán las que indicaban los propios miembros del equipo que diseño el lenguaje:



Por la otra parte, no se puede negar que los parámetros opcionales son una característica cómoda y práctica. Por ejemplo, supongamos que queremos escribir un método con cuatro parámetros con “valores por defecto”. Hoy por hoy, podríamos programar CINCO (n + 1) sobrecargas, donde cada una de las ellas (excepto la última) le “pasa la pelota” a alguna otra. Algo bastante mecánico (que no macánico, que diría Cabrera Infante :-), que el compilador podría hacer por nosotros él solito.


Por ejemplo, lo que en C# 4 expresaremos con:


   int Suma(int a = 0, int b = 0, int c = 0, int d = 0) { return a + b + c + d; } 


podríamos codificarlo hoy mediante la siguente “escalera”:


   int Suma() { return Suma(0, 0, 0, 0); } 
   int Suma(int a) { return Suma(a, 0, 0, 0); } 
   int Suma(int a, int b) { return Suma(a, b, 0, 0); } 
   int Suma(int a, int b, int c) { return Suma(a, b, c, 0); } 
   int Suma(int a, int b, int c, int d) { return a + b + c + d; } 


Si C# 4 solo añadiera los parámetros opcionales, esta “generación automática de  sobrecargas” podría ser una manera muy válida de implementarlos. Pero la cosa se complica (en la medida en que se abren nuevas posibilidades) con la incorporación de los parámetros nombrados.


Los parametros nombrados nos permitirán hacer llamadas como la siguiente al método Suma anterior:


   int n = Suma(b:5, c:7); // valores por defecto para parámetros a y d


Gracias a la combinación de los parámetros opcionales y nombrados, ahora no estaremos limitados a n + 1, sino que podremos cubrir todas las posibles combinaciones de argumentos explícitos/implícitos en las llamadas, 2 ^ n (en este nuestro ejemplo DIECISEIS). NOTA: ¿Se da cuenta de las dificultades asociadas a implementar esto mediante sobrecargas?


Sea cual fuera la implementación interna de estas características, es un hecho objetivo que garantizan una comodidad y economía de expresión significativas.


Otras ideas que me vienen a la mente sobre este tema:




  • Aunque seguramente los programadores de C# aplicarán de manera creativa estas nuevas características cuando estén disponibles, pienso que el equipo de C# no se habría decidido a incorporarlas al lenguaje si no fuera por la necesidad de disponer de ellas para facilitar la programación de aplicaciones que utilicen el modelo “de objetos” cuasi-prehistórico de Office, en el que son típicos los métodos con 10 ó más parámetros, muchos de ellos opcionales.


  • Las tablas de metadatos de .NET en los que se almacena la información sobre los parámetros de métodos incluyen la posibilidad de establecer la opcionalidad y asignar valores por defecto a todos y cada uno de ellos (ver Lidin, “Expert .NET 2.0 IL Assembler”, pág. 190). Por lo tanto, no era descabellado pensar que añadieran esta posibilidad a C# en algún momento…

 

Octavio Hernandez

Desarrollador y consultor en tecnologías .NET. Microsoft C# MVP entre 2004 y 2010.

3 comentarios en “Más sobre los parámetros opcionales y nombrados

  1. MMMmm…
    Totalmente de acuerdo sobre lo que comentas de Office 🙂

    Y por otro lado, menos mal que han optado por parámetros nombrados y no por la horrible (en mi opinión) sintaxis tipo Suma(1,,,4)

    Por otro lado… tenemos parámetros genéricos por defecto, o eso ya es pedir demasiado??? 🙂

  2. Eduard,

    Totalmente de acuerdo, esa otra sintaxis (leading to comma-counting code, como dicen en el documento preliminar) es horripilante…

    Los parámetros genéricos por defecto se quedan para la próxima, como varias otras cosas :-(. Según miembros del equipo, C# 4 es una edición relativamente pequeña, centrada alrededor del soporte para el tipado dinámico (interacción con Silverlight, Office y lenguajes como Ruby, Python o el “VB con Strict Off”).

    Slds – Octavio

  3. Pues, la verdad estan muy bien, he visto muchas funciones que reciben object[] o coleciones y luego hacen el cast para convertirlos a su tipo y evitar pasar muchos parametros, me parece mucho mas elegante esta solución, es similar a la solución de linq, parece que es otro “azucar sintactico”, en el que el compilador creara los metodos sobreecargados necesarios para resolver el metodo.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *