¿Cómo elijo un nombre de paquete para un módulo de Perl personalizado que no colisione con nombres de paquetes incorporados o CPAN?

Question

He leído el perldoc on modules, pero no veo una recomendación para nombrar un paquete, por lo que no colisionará con los nombres incorporados del paquete/módulo CPAN.

En el pasado, para desarrollar un módulo local Session.pm, he creado un directorio local utilizando el nombre de mi empresa, tales como:

package Company::Session; 

... y Session.pm que se encontraría en el directorio Empresa/.

Pero simplemente no soy un fanático de esta convención de nomenclatura. 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 falta algo fundamental. También miré en Damian's Perl Best Practices pero es posible que no haya estado buscando en el lugar correcto ...

¿Alguna recomendación sobre cómo evitar las colisiones del espacio de nombres del paquete de la manera correcta?

actualización w/pregunta relacionada: si hay es un nombre de paquete conflicto, ¿cómo Perl elegir cuál usar? Gracias a todos.

Answer 1

El espacio de nombre 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 llamados 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 que 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 se resuelve un conflicto Perl:

Perl busca en los directorios en los @INC para un módulo con el nombre especificado. El primer módulo encontrado es el utilizado. Por lo tanto, 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 reportará el contenido 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á handle multiple modules with the same name by different authors, e incluso usar más de uno en un solo programa. Pero eso no resuelve tu problema ahora.

Answer 2

¿Qué hay de malo con solo elegir un nombre para su paquete que le guste y luego buscar en Google "perl el nombre-elegido-"?

Answer 3

Si necesita el nivel máximo de certeza de que su nombre de 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 compañía. 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. La ventaja de la primera es que si tiene varias subunidades todos ellos pueden tener su propio espacio de nombres, pero los módulos seguirá siendo una especie juntos:

• Com :: ejemplo :: :: Biz FindCustomers
• Com: : Ejemplo de TI :: :: ParseLogs
• Com :: :: Ejemplo de control de calidad :: TestServer

pero que tiene un aspecto extraño al principio.

Answer 4

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.

Answer 5

(Sé que este post es viejo, pero como he tenido que resolver esto en los últimos meses, pensé que pesaría en)

En el trabajo hemos decidido que 'local ::' Me sentí 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 'Our ::'. 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.

Nuestra :: datos es nuestra clase :: módulo DBI :: Nuestra aplicación es nuestro marco de aplicación genérica que hace el manejo de configuración y esas cosas Getopt

agradable de leer y agradable para escribir.

Answer 6

La variable @INC contiene una lista de directorios en los que 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 crea cuando se compila el Perl, pero se puede se puede cambiar con la variable PERL5LIB medio ambiente, la lib pragma, y directamente la manipulación de 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:)