Bueno, CPAN está lleno de pequeñas joyas... lo que hay que hacer es estar atento a las
novedades o, lo más normal, leer código que hacen otros programadores.
También te encontrarás con puristas del lenguaje y jefes de desarrollo que no quieren oír hablar de nuevos módulos, porque eso implica que tu programa tiene más 'dependencias' del exterior, y eso implica un trabajo extra para mantenerlo (¡Como si los programadores de Java fueran capaces de vivir sin sus bibliotecas externas!
).
En última instancia, el código está disponible, así que podríamos mirar qué es lo que hace
utf8::all, y quedarnos con aquella parte del código que realmente nos interesa.
Lo importante es entender qué hace ese módulo en este programa, el porqué lo estamos usando.
- decodifica los argumentos (@ARGV) en utf8
- las entradas y salidas de archivos, serán también en esa codificación (use open qw(:utf8 :std))
- incluso el código fuente contendrá caracteres así (use utf8)
Así que nos hemos ahorrado unas pocas líneas.
Tema interesante: los anglosajones no necesitan de la codificación utf8, o al menos no la han necesitado durante años, ya que la informática está dictada por ellos. Perl es un ejemplo de ello: si no dices nada, usará siempre la codificación por defecto iso-8859-1, que es la del alfabeto occidental. Por eso vemos cantidad de códigos que luego queremos hacer funcionar en nuestras máquinas y sí, funcionan, pero nos encontramos con problemas que son específicos de nuestro alfabeto (los caracteres tildados). Los programadores novatos escribirán cosas como esta:
Using perl Syntax Highlighting
print "La solución es: \n";
Coloreado en 0.001 segundos, usando
GeSHi 1.0.8.4
y se encuentran con que no ven la 'ó' en la pantalla, sino unos caracteres extraños. Y por no romperse la cabeza, deciden que lo más cómodo es quitar todos los caracteres tildados del código fuente. Se hubiera arreglado con un par de líneas, como ya hemos visto, indicando que la codificación usada era iso-8859-15 (la occidental, más el €uro).
Desde hace unos años, todos los sistemas ya están funcionando en utf8, así que ha cobrado importancia también entre los anglosajones, y Perl se ha convertido en el lenguaje con
mejor soporte de utf8.
Si vemos ahora código de los anglosajones, veremos que ellos usan el utf8 cuando ya no les queda más remedio (hablar con una base de datos, por ejemplo). En cambio, nosotros, estamos obligados a usarlo siempre, ya que a) nuestras terminales funcionarán con esa codificación
Using bash Syntax Highlighting
$ echo $LANG
es_ES.UTF-8
Coloreado en 0.002 segundos, usando
GeSHi 1.0.8.4
y b) necesitamos usar caracteres tildados cada dos por tres (
print "Solución").
La ventaja es que, además, podemos usar esos caracteres tildados para los nombres de las variables:
Using perl Syntax Highlighting
my($solución
, $es_fácil
, @cañones
);Coloreado en 0.001 segundos, usando
GeSHi 1.0.8.4
Algunos recomiendan no hacerlo, pero, si hablamos de un programa que es para "consumo interno" nuestro, yo lo encuentro de lo más normal del mundo (y si no, basta con mirar algún código Perl en japonés
)
En cuanto a lo de los
hash, estoy completamente de acuerdo contigo: es una línea algo complicada, y ni siquiera a mi me resulta natural. Hubiera preferido hacer
Using perl Syntax Highlighting
my %alfa_a_num;
for my $i (0 .. $#alfabeto) {
$alfa_a_num{$alfabeto[$i]} = $i;
}
Coloreado en 0.001 segundos, usando
GeSHi 1.0.8.4
que es mucho más claro. O incluso un
Using perl Syntax Highlighting
$alfa_a_num{$alfabeto[$_]} = $_ for 0 .. $#alfabeto;
Coloreado en 0.001 segundos, usando
GeSHi 1.0.8.4
O como lo tenías hecho tú:
Using perl Syntax Highlighting
@alfa_a_num{@alfabeto} = 0 .. $#alfabeto;
Coloreado en 0.001 segundos, usando
GeSHi 1.0.8.4