[Madrid-pm] Consejos importantes

[DervishD]

    Hola Salva :)

 * Salvador Fandiño <sfandino en yahoo.com> dixit:
> > ¿Sería mejor, como yo creo, echar un ojo a CPAN y a los "core
> > modules" e intentar encajar mi código en esa jerarquía, o sería
> > mejor empezar mi propia jerarquía y asegurarme así que no habrá
> > conflictos en los nombres de los "packages"? Por ejemplo, tengo una
> > función de getopt (miré TODAS las de CPAN y no me gustó ninguna, a
> > todas les faltaba algo que yo quería tener) y no sé si meterla en
> > "DervishD::Getopt" o bien en "Getopt::DD" (o algo así). Me inclino
> > por la segunda opción, siempre que encuentre un nombre para el
> > package ;))))
> 
> Deberias tambien plantearte si lo que hace tu modulo es tan importante
> como para no poder vivir sin ello.

    En general, lo es, y no sólo hablo de mi getopt, es más importante
la función "run", por ejemplo, y aprovechando que voy a hacer arreglos
en el código y a limpiar todo lo que pueda (y por tanto, a separar el
batiburrillo de código por categorías), quería también hacer una
jerarquía, no tanto para ponerlos en CPAN (que dudo mucho que acaben
ahí) sino por tener una mejor organización incluso para mi uso personal.

    En realidad, quien usa y mantiene (ahora) el código que usa
"Common.pm" soy yo, de forma que todas estas mejoras las hago
principalmente para mí. Podría usarlo tal cual, pero después de leer el
PBP no me sentiría cómodo sabiendo que ciertas cosas están muy mal
hechas, y no por una cuestión de integrismo o por creer a ciegas en el
PBP, sino porque muchas de las explicaciones de Conway me parecen muy
convincentes.

> Getopt::Std y Getopt::Long puede que no sean perfectos, pero son el
> estandar de facto y la mayoria de programadores de Perl saben como
> funcionan. Si usas un modulo distinto, al que le toque mantener tus
> programas, tendra que aprender a usarlo y total para una cosa
> secundaria como es interpretar la lista de argumentos.

    Eso no es un problema, ese código lo voy a mantener yo (y estoy
seguro de ello, es una larga historia pero nadie va a mantener mi
código...). Cuando escribo código que seguro voy a compartir, paso de
poner mis propias soluciones sólo porque yo crea que son mejores: uso
lo estándar y ya está, aunque le falte algún "toque". Me da por saco
mantener código en el que muchas cosas que se podrían hacer de forma
estándar se hacen con soluciones "ad hoc". Pero por otro lado tampoco me
gusta demasiado usar código que depende de 25 módulos de CPAN, sobre
todo cuando son módulos poco conocidos y poco probados.

> Existe tambien otra via, que es modificar alguno de los modulos que ya
> existen y tratar de que el autor incorpore las modificaciones. Si
> realmente lo que aportas vale la pena, lo normal es que no haya mucha
> resistencia a hacerlo.

    Intenté meterle mano a Getopt::Long hace mucho, y me dí cuenta de
que iba a tardar menos en escribir algo nuevo. Tardé más en leer el
código de Getopt::Long que en escribir mi función (que me llevó sólo una
hora o así). Pero sí, siempre miro el código antes a ver si simplemente
modificándolo puedo conseguir algo. El problema es que si luego el
cambio no se acepta (porque, por ejemplo, lo que aporte no valga la pena
para un uso general), me tocaría mantener por mi cuenta el código
modificado, y eso es peor algunas veces que empezar desde cero.

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!