studio - seleccionar columnas en r

¿Cuál es el beneficio de importar en un espacio de nombres en R?

Question

El mecanismo de espacio de nombres de R permite export funciones que luego son visibles para el usuario. Además, permite import funciones desde otros paquetes. Mientras que el beneficio de la exportación es obvio, tengo más problemas para entender el beneficio de la importación.

Un beneficio parece ser que se pueden usar funciones de otros paquetes sin adjuntar el paquete y, por lo tanto, ahorrar memoria. Esto se ejemplifica en la sección 1.6.4 del manual de extensiones R de escritura .

Sin embargo, debe haber otros beneficios de la función de importación. Especialmente, la sección 1.6.6 (que trata de las clases de S4) muestra el namespace de namespace del paquete stats4:

 export(mle)
 importFrom("graphics", plot)
 importFrom("stats", optim, qchisq)
 ## For these, we define methods or (AIC, BIC, nobs) an implicit generic:
 importFrom("stats", AIC, BIC, coef, confint, logLik, nobs, profile,
            update, vcov)
 exportClasses(mle, profile.mle, summary.mle)
 ## All methods for imported generics:
 exportMethods(coef, confint, logLik, plot, profile, summary, show, update, vcov)
 ## implicit generics which do not have any methods here
 export(AIC, BIC, nobs)

Aquí hay funciones importadas que no son ni clases de S4 ni genéricas (donde tendría sentido usar la importación también, como se documenta en el ejemplo de esa sección ), pero funciona como la plot del paquete de graphics que se cargan automáticamente cuando R comienza.

Por lo tanto, mi pregunta es, ¿cuál es el beneficio de importar funciones como plot , optim o qchisq ?

Answer 1

Si una función foo se importa de la barra de paquetes, se encuentra independientemente de lo que haga el usuario en su ruta de búsqueda, por ejemplo, al adjuntar un paquete Baz que también tiene una función foo . Sin un espacio de nombre, el código del paquete se encontraría repentinamente usando Baz::foo . También hay problemas de eficiencia (se encuentra foo inmediatamente, en lugar de después de buscar todos los símbolos en la ruta de búsqueda), pero es probable que sean triviales para la mayoría de las aplicaciones. De la misma manera, importFrom es una mejora sobre la import debido a menos colisiones (o uso de funciones involuntarias) y una búsqueda más eficiente.

Con S4 (y S3) las cosas pueden complicarse bastante. Una función no genérica como graphics::plot se puede promover a un genérico (con setGeneric ) en dos paquetes diferentes, y cada genérico puede tener su propio conjunto de métodos adjuntos. El autor de un paquete querrá ser preciso sobre qué plot genérico y, por lo tanto, qué tabla de despacho de métodos, sus clases y métodos se pueden ver.

Llamar a una función con pkg::foo siempre se resuelve en la función deseada. Requiere que pkg esté listado en el campo Depende: del archivo de DESCRIPCIÓN (tal vez en Importaciones: pero luego parece una publicidad engañosa para no importar desde pkg), contaminando la ruta de búsqueda del usuario. También implica dos búsquedas de símbolos y una llamada a función ( :: , y por lo tanto es menos eficiente. La parte perezosa y la falta de atención al detalle de mi persona también ve el uso de :: como tedioso y propenso a errores.

El paquete codetoolsBioC (a través de svn con nombre de usuario y contraseña de readonly ) puede generar un archivo NAMESPACE a partir de un paquete existente (o, al menos, antes de que los cambios recientes en R-devel introdujeran un NAMESPACE en paquetes sin uno; no he probado codetoolsBioC en tales un paquete).