programacion - ¿Es una buena práctica llamar a funciones en un paquete a través de:

manual de r pdf

Question

Estoy escribiendo algunas funciones R que emplean algunas funciones útiles en otros paquetes como stringr y base64enc . ¿Es bueno no llamar a la library(...) o require(... ) cargar estos paquetes primero, sino usar :: para referirse directamente a la función que necesito, como stringr::str_match(...) ?

¿Es una buena práctica en general? ¿O qué problema podría inducir?

Answer 1

Todo depende del contexto.

:: es principalmente necesario si hay colisiones de espacio de nombres , funciones de diferentes paquetes con el mismo nombre. Cuando cargo el paquete dplyr , proporciona un filter función, que choca con (y enmascara) la función de filter cargada por defecto en el paquete de stats . Entonces, si quiero usar la versión de stats de la función, necesitaré llamarla con stats::filter . Esto también da motivación para no cargar muchos paquetes . Si realmente solo desea una función de un paquete, puede ser mejor usar :: que cargar todo el paquete, especialmente si sabe que el paquete enmascarará otras funciones que desee usar.

No en el código, pero en el texto, encuentro :: muy útil. Es mucho más conciso escribir stats::filter que "la función de filter en el paquete de stats ".

Desde una perspectiva de rendimiento , hay un precio (muy) pequeño por usar :: . Martin Maechler escribió (en la lista de correo de r-devel (septiembre de 2017) )

Mucha gente parece olvidar que cada uso de :: es una llamada a la función R y su uso es ineficiente en comparación con el uso del nombre ya importado.

La penalización de rendimiento es muy pequeña , del orden de unos pocos microsegundos, por lo que es solo una preocupación cuando se necesita un código altamente optimizado. Ejecutar una línea de código que usa :: un millón de veces tomará uno o dos segundos más que el código que no usa :: .

En lo que se refiere a la portabilidad, es bueno cargar paquetes de manera explícita en la parte superior de un script, ya que hace que sea fácil echar un vistazo a las primeras líneas y ver qué paquetes se necesitan, instalarlos si es necesario antes de profundizar en cualquier otra cosa, es decir, , llegando a la mitad de un largo proceso que ahora no se puede completar sin volver a empezar.

Aparte : se puede hacer un argumento similar para preferir library() en vez de require() . La biblioteca causará un error y se detendrá si el paquete no está allí, mientras que require avisará pero continuará. Si su código tiene un plan de contingencia en caso de que el paquete no esté allí, entonces, por todos los medios use if (require(package)) ... , pero si su código fallara sin un paquete, debería usar library(package) en el arriba para que falle temprano y claramente. (Gracias a Hugh y BondedDust en los comentarios.)

Escribiendo tu propio paquete

La solución general es crear su propio paquete que imports los otros paquetes que necesita usar en el archivo de DESCRIPCIÓN. Esos paquetes se instalarán automáticamente cuando tu paquete esté instalado, por lo que puedes usar pkg::fun internamente. O bien, importándolos también en el archivo NAMESPACE , puede import un paquete completo o importFrom selectivamente importFrom funciones específicas y no necesita :: . Las opiniones difieren sobre esto. El miembro de R-Core Martin Maechler (la misma fuente de r-devel que arriba) dice:

Personalmente, tengo la impresión de que :: está muy "sobreutilizado" en la actualidad, especialmente en paquetes en los que abogaba por el uso de importFrom () en NAMESPACE, por lo que todo esto sucede en el momento de carga del paquete y luego no se usa :: en el paquete de fuentes en sí.

Por otro lado, el destacado desarrollador de paquetes Hadley Wickham dice en su libro R Packages :

Es común que los paquetes se enumeren en Imports en DESCRIPTION , pero no en NAMESPACE . De hecho, esto es lo que recomiendo: liste el paquete en DESCRIPTION para que esté instalado, luego refiérase siempre a él con pkg::fun() . A menos que haya una razón fuerte para no hacerlo, es mejor ser explícito.

Con dos estimados expertos en R que dan recomendaciones opuestas, creo que es justo decir que debe elegir el estilo que mejor se adapte a sus necesidades y claridad, eficiencia y facilidad de mantenimiento.

Si con frecuencia se encuentra usando solo una función de otro paquete, puede copiar el código y agregarlo a su propio paquete. Por ejemplo, tengo un paquete para uso personal que toma prestado %nin% del paquete Hmisc porque creo que es una gran función, pero a menudo no uso nada más de Hmisc . Con roxygen2 , es fácil agregar @author y @references para atribuir correctamente el código para una función prestada. También asegúrese de que las licencias del paquete sean compatibles al hacer esto.