martes, 7 de octubre de 2014
Cuando los lenguajes evolucionan, no todas las novedades son espectaculares ni revolucionan la forma de escribir nuestro código. A veces la cosa va simplemente de añadir pequeños detalles que nos hacen la vida más fácil y ayudan a evitar errores.
Y hoy hablaremos de uno de ellos: el nuevo operador
Imaginad un escenario que podría ser bastante frecuente, como el siguiente:
Observad que mediante el uso de las constantes
El problema que tiene esto es que si más adelante decidimos refactorizar y modificar el nombre de los parámetros, muy probablemente olvidaremos modificar estas cadenas de texto, por lo que la excepción no mostrará información correcta sobre el error.
Para solucionar este escenario, C# 6 incluirá el operador
¡Voila! Como sabréis, conseguir algo similar sin un operador como el que nos regala la nueva versión de C# sería bastante más complejo y farragoso. El operador
Volviendo al primer ejemplo, ahora podemos escribir el mismo método, pero asegurando que la información de ayuda de la excepción siempre incluirá el valor correcto, a prueba de refactorizaciones:
Pero no sólo de variables locales y parámetros se alimenta el operador
Aunque hay otros usos que no son tan intuitivos. Por ejemplo, para referenciar miembros de instancia hay que hacerlo como si fueran miembros estáticos de la clase donde residen:
Además de para facilitar el trazado de errores, hay muchos otros escenarios en los que este nuevo operador podría ayudarnos a cometer menos errores. Así a bote pronto, se me ocurre que en MVC podría ser una vía sencilla para evitar las constantes de cadena si quisiéramos añadir errores al
También sería de utilidad, por ejemplo, si quisiéramos implementar un interfaz
En definitiva, una pequeña incorporación al lenguaje que puede resultar utilísima en esos escenarios en los que debemos referenciar mediante una cadena de texto el nombre de elementos definidos a nivel de código.
Por último, recordaros que C# 6 traerá muchas otras novedades. Si queréis conocerlas, no os perdáis los posts anteriores de la serie:
Y hoy hablaremos de uno de ellos: el nuevo operador
nameof
, que acompañará a C# a partir de su versión 6.Imaginad un escenario que podría ser bastante frecuente, como el siguiente:
Observad que mediante el uso de las constantes
"firstString"
y "secondString"
estamos introduciendo una dependencia en nuestro código entre dos elementos que viven en mundos diferentes, como son el nombre de una variable a nivel de código y la cadena que representa el nombre de dicho parámetro en tiempo de ejecución.El problema que tiene esto es que si más adelante decidimos refactorizar y modificar el nombre de los parámetros, muy probablemente olvidaremos modificar estas cadenas de texto, por lo que la excepción no mostrará información correcta sobre el error.
Para solucionar este escenario, C# 6 incluirá el operador
nameof
que, como se puede intuir, nos ayudará a conocer en tiempo de ejecución el nombre de una variable o miembro tal y como ha sido definida en la codificación. El ejemplo más sencillo que podemos ver es el siguiente:¡Voila! Como sabréis, conseguir algo similar sin un operador como el que nos regala la nueva versión de C# sería bastante más complejo y farragoso. El operador
nameof
simplemente retornará en forma de cadena de texto el nombre de la variable que le indiquemos.Volviendo al primer ejemplo, ahora podemos escribir el mismo método, pero asegurando que la información de ayuda de la excepción siempre incluirá el valor correcto, a prueba de refactorizaciones:
Pero no sólo de variables locales y parámetros se alimenta el operador
nameof
;-) En realidad podemos pasarle casi cualquier cosa, y su comportamiento será siempre el esperado:Aunque hay otros usos que no son tan intuitivos. Por ejemplo, para referenciar miembros de instancia hay que hacerlo como si fueran miembros estáticos de la clase donde residen:
Además de para facilitar el trazado de errores, hay muchos otros escenarios en los que este nuevo operador podría ayudarnos a cometer menos errores. Así a bote pronto, se me ocurre que en MVC podría ser una vía sencilla para evitar las constantes de cadena si quisiéramos añadir errores al
ModelState
de un controlador (cosa que, por otra parte, no es especialmente recomendable):También sería de utilidad, por ejemplo, si quisiéramos implementar un interfaz
INotifyPropertyChanged
o cualquier otro que requiera conocer el nombre del miembro actual. De nuevo, simplemente haciendo uso de nameof
podremos averiguar con facilidad el nombre de la propiedad que cambió para pasarlo al evento oportuno.En definitiva, una pequeña incorporación al lenguaje que puede resultar utilísima en esos escenarios en los que debemos referenciar mediante una cadena de texto el nombre de elementos definidos a nivel de código.
Por último, recordaros que C# 6 traerá muchas otras novedades. Si queréis conocerlas, no os perdáis los posts anteriores de la serie:
- El operador “-.” en C# y VB.NET, más cerca
- Inicialización de propiedades en C# 6.0
- Uso de miembros estáticos en C# 6, ¿una buena idea?
- Declaración de variables en expresiones de C# 6
5 Comentarios:
Muy interesante novedad.
Me pregunto la incidencia en el rendimiento de nameof.
Por ejemplo, el típico Unit Test que aparece con los gurus de CodeProject con un for 1 to 10000000000000, y a realizar mediciones de performance.
Saludos
Hola!
Es una pregunta interesante, a ver si un día tengo un rato y lo compruebo a base de descompilador.
Por intuición, diría que el rendimiento del operador debería ser el mismo que a utilizar una constante string con el nombre, puesto que nameof() debería ser resuelto en tiempo de compilación y no en ejecución. Pero lo dicho, sin verlo con reflector o similar no hay pruebas ;)
Saludos.
Me sentí identificado con lo del primer parrafo, creo que fue un guiño al comentario en tu anterior entrega sobre estas novedades ;)
Ahora bien respecto al contenido batalle un poco en encontrarle algún uso a esta característica, pero sin duda es algo que te ahorrara cambios y lo mejor te abstrae de cosas mas laboriosas.
Por último siempre he tenido una curiosidad y sin que parezca una "felación intelectual" ¿A que se debe que gran parte de los "bloggers" informáticos españoles tengan un nivel alto en desarrollo y sobre todo esten enterados de novedades o bien dominan tecnologías nacientes o muy nuevas (en tu caso SignalR o MVC)?
Gracias en nombre de mis compatriotas :-DDDDDD
No sé la percepción que tendréis desde ahí, pero a día de hoy no creo que dependa de la localización geográfica. Quizás hace unos años sí podía existir diferencia por la facilidad de acceso a recursos e información, pero internet cambió eso: todo está disponible para todos en el mismo momento. La información está ahí, sólo hay que ir a buscarla.
La gente de gran nivel que tengo la suerte de conocer son lo que son porque le dedican mucho tiempo y esfuerzo y les encanta lo que hacen. Pero no hay nada geográfico en ello, eso debe ocurrir en España, México, Argentina, y en cualquier parte del mundo :)
Saludos & gracias por comentar!
Curiosa novedad siendo que hace un par días esta me hubiera facilitado un trabajo. Ya no recuerdo el escenario, pero al final solucioné mi problema de otra manera.
Durante mi búsqueda me pareció interesante leer una gran cantidad de publicaciones en las que preguntan como obtener los nombres de las variables, pero no están conscientes del por qué de que los nombres no estén disponibles en tiempo de ejecución.
Con respecto al rendimiento coincido contigo completamente. Creo que se trata de una 'simple' sustitución, pero habrá que esperar.
Un abrazo.
Enviar un nuevo comentario