Pues eso… viendo las novedades de C# 10.0 me he topado con los detalles de la «novedad» Global using directives, dicho de esa forma parece algo «WOW!», y… es algo que siempre he querido que quitasen de forma predeterminada al crear un nuevo proyecto de Visual Basic para .NET: que haya importaciones implícitas de espacios de nombres al crear un nuevo proyecto.

Y eso es lo que es esa «nueva» característica de C# 10.0, crear definiciones «using» (ya que «Imports» es cosa de Visual Basic para .NET) de los espacios de nombres más habituales según el tipo de proyecto creado.

Que sí, que está muy bien, pero a mí nunca me ha gustado, de hecho, en la mayoría de los proyectos que creaba (sobre todo si era para compartirlo como parte de algún artículo), lo quitaba, con idea de así tener que escribir las importaciones de espacios de nombres en cada fichero (de código) de ese proyecto. Porque es la única forma de saber «a ciencia cierta» qué espacios de nombres se estaban usando en ese fichero de código.

Para que nos entendamos, a diferencia de C#, en Visual Basic el espacio de nombres System.Text nunca se importa de forma predeterminada, algo que sí ocurre en los proyectos de C#; por tanto, si quiero crear un nuevo objeto del tipo StringBuilder, o bien lo creo usando el nombre «completo» de la clase StringBuilder: System.Text.StringBuilder o bien declaro la importación del espacio de nombres System.Text y ya el compilador sabrá que StringBuilder está accesible (al revisar las clases contenidas en cada uno de los espacios de nombres que estén incluidos en las importaciones).

¡Eh! que no es una crítica, que me parece muy bien, y si ahora los del TEAM de C# lo están añadiendo como algo «predeterminado» será porque tampoco será tan malo, lo único que digo es que sigue siendo lo mismo que teníamos los «desarrollado-res» de Visual Basic desde hace ya casi 20 años… ¡NOVEDAD! WOW! 😉

Total, a lo que iba, que ya no hace falta seguir dando nuevas características a Visual Basic, porque al final C# será como era Visual Basic hace 20 años… eso sí, con (entre otras cosas) acabando la línea con un punto y coma.

Pero preferiría que Visual Basic evolucionara con las «nuevas características» realmente nuevas, para que a los que no nos gusta usar punto y coma para indicar que una instrucción ha finalizado o poner cosas entre llaves, etc., etc., y dejar de ver cómo C# evoluciona para hacer cosas que desde «siempre» ha hecho Visual Basic y, casi seguro, que era criticado por eso… Y si no me crees, échale un vistazo a las declaraciones sin tipos de variables (que, siempre al estilo de C#) en C# también lo añadieron en su día como novedad novedosa…

Nos vemos.
Guillermo