usos - ¿Cómo elijo un nombre de paquete para un módulo personalizado de Perl que no colisione con nombres de paquetes incorporados o CPAN?
perl ventajas y desventajas (6)
¿Qué hay de malo con solo elegir un nombre para tu paquete que te gusta y luego buscar en Google "Perl the-name-you-picked "?
He leído el perldoc en los módulos , pero no veo una recomendación para nombrar un paquete, por lo que no colisionará con los nombres integrados del paquete / módulo CPAN.
En el pasado, para desarrollar un módulo local Session.pm, he creado un directorio local usando el nombre de mi compañía, como por ejemplo:
package Company::Session;
... y Session.pm se encontraría en el directorio Company /.
Pero simplemente no soy un fanático de esta convención de nombres. Preferiría nombrar la jerarquía del paquete más cerca de la funcionalidad del código. Pero así es como se hace en CPAN en general ...
Siento que me estoy perdiendo algo fundamental. También miré en las mejores prácticas de Perl de Damian, pero es posible que no haya estado buscando en el lugar correcto ...
¿Alguna de las recomendaciones sobre cómo evitar el espacio de nombres del paquete colisiona de la manera correcta?
Actualización con Pregunta relacionada : si hay un conflicto de nombre de paquete, ¿cómo elige Perl cuál usar? Gracias a todos.
(Sé que esta publicación es antigua, pero como he tenido que resolver esto en los últimos meses, pensé que sería útil)
En el trabajo, decidimos que ''Local ::'' se sentía demasiado geográfico. CompanyName :: también tuvimos algunos problemas que no están relacionados con el desarrollo, los saltearé, aunque diré que CompanyName es largo cuando hay que escribirlo docenas de veces.
Así que nos decidimos por ''Nuestro ::''. Claro, no somos ''CPAN Safe'' ya que podría haber un día en que deseemos usar un módulo CPAN con el prefijo Our ::. Pero se siente bien.
Our :: Data es nuestro módulo Class :: DBI Our :: App es nuestro framework de aplicaciones genéricas que hace manejo de configuraciones y cosas Getopt
Agradable de leer y agradable de escribir.
El espacio de nombres Local:: se ha reservado solo para este propósito. Ningún módulo que comience con ese prefijo será aceptado en CPAN o en el núcleo. Alternativamente, puede usar un guión bajo en el nombre de nivel superior (como My_Corp::Session o simplemente My_Session ). Todas las categorías con un guión bajo también han sido reservadas. (Esto se menciona en perlmodlib , en "Seleccionar un nombre para el módulo").
Tenga en cuenta que ambas reservas se aplican solo al nombre de nivel superior. Por ejemplo, hay módulos de CPAN denominados Time::Local y Text::CSV_XS . Pero Local::Time y Text_CSV::XS son nombres reservados y no se aceptarán en CPAN.
Nombrar módulos después de su empresa también está bien. (Bueno, a menos que trabaje para una compañía de sonido realmente genérica.) Usar el nombre de dominio inverso probablemente sea excesivo, a menos que pretenda distribuir sus módulos a otros. (Pero en ese caso, probablemente debería registrar un nombre de módulo normal).
Cómo Perl resuelve un conflicto:
Perl busca en los directorios en @INC un módulo con el nombre especificado. El primer módulo encontrado es el utilizado. Entonces, el orden de los directorios en @INC determina qué módulo se usará (si tiene módulos con el mismo nombre instalados en diferentes ubicaciones).
perl -V informará los contenidos de @INC (los directorios de mayor prioridad se enumeran primero). Pero también hay muchas maneras de manipular @INC en tiempo de ejecución.
Por cierto, Perl 6 podrá manejar múltiples módulos con el mismo nombre por diferentes autores , e incluso usar más de uno en un solo programa. Pero eso no resuelve tu problema ahora.
La variable @INC contiene una lista de directorios en donde buscar módulos. Comienza con la primera entrada y luego pasa al siguiente si no encuentra el módulo de solicitud. @INC tiene un valor predeterminado que se creó cuando se compila Perl, pero puede cambiarlo con la variable de entorno PERL5LIB , el pragma de lib y manipulando directamente la matriz @INC en un bloque BEGIN :
#!/usr/bin/perl
BEGIN {
@INC = (); #no modules can be found
}
use strict; #error: Can''t locate strict.pm in @INC (@INC contains:)
No hay nada de malo en nombrar sus módulos internos después de su empresa; Yo siempre hago esto El 90% de mi código termina en CPAN, por lo que tiene nombres "normales", pero las cosas internas siempre comienzan con ClientName:: .
Estoy seguro de que todos los demás también lo hacen.
Si necesita el máximo nivel de certeza de que el nombre de su módulo no entrará en conflicto con el de otra persona, puede tomar una página del libro de Java: nombre el módulo con el nombre del dominio de la empresa. Entonces, si trabajas para Example, Inc. y su nombre de dominio es example.com, deberías nombrar tu módulo de análisis HTML Com :: Example :: HTML :: Parser o Example :: Com :: HTML :: Parser. El beneficio del primero es que si tiene múltiples subunidades, todas pueden tener su propio espacio de nombres, pero los módulos aún se ordenarán juntos:
- Com :: Example :: Biz :: FindCustomers
- Com :: Example :: IT :: ParseLogs
- Com :: Example :: QA :: TestServer
pero parece extraño al principio.