Escribir código R robusto: espacios de nombres, enmascarar y usar el operador `::`

Versión corta

Para aquellos que no quieren leer a través de mi "caso", esta es la esencia:

1. ¿Cuál es la forma recomendada de minimizar las posibilidades de que nuevos paquetes rompan el código existente, es decir, de hacer que el código que escribe sea lo más robusto posible?

2. ¿Cuál es la forma recomendada de hacer el mejor uso del mecanismo de espacio de nombres cuando

   A) solo usando paquetes contribuidos (digamos en algunos análisis de R Project)?

   B) con respecto a desarrollando paquetes propios?

3. ¿Cuál es la mejor manera de evitar conflictos con respecto a clases formales (principalmente Clases de referencia en mi caso) ya que ni siquiera hay un mecanismo de espacio de nombres comparable a :: para las clases (AFAIU)?

La forma en que funciona el universo R{[18]]}

Esto es algo que ha estado molestando en el fondo de mi mente durante unos dos años, sin embargo, no siento como si llegar a una solución satisfactoria. Además siento que está empeorando.

Vemos un número cada vez mayor de paquetes en CRAN, github, R-Forge y similares, lo cual es simplemente fantástico.

En un entorno tan descentralizado, es natural que la base de código que compone R (digamos que es base R y contribuido R , por simplicidad) se desvíe de un estado ideal con respecto a la robustez: la gente sigue convenciones, hay Clases de Referencia S3, S4, S4, etc. Las cosas no pueden estar tan "alineadas" como lo estarían si hubiera una "instancia central de compensación" que hiciera cumplir las convenciones. Está bien.

El problema

Dado lo anterior, puede ser muy difícil usar R para escribir código robusto. No todo lo que necesitas estará en base R. Para ciertos proyectos terminarás cargando bastantes paquetes contribuidos.

En mi humilde opinión, el mayor problema en ese sentido es la forma el concepto de espacio de nombres se usa en R: R permite simplemente escribir el nombre de una determinada función / método sin requerir explícitamente su espacio de nombres (es decir, foo vs.namespace::foo).

Así que en aras de la simplicidad, eso es lo que todos están haciendo. Pero de esa manera, los conflictos de nombres, el código roto y la necesidad de reescribir/refactorizar su código son solo cuestión de tiempo (o del número de paquetes diferentes cargados).

En el mejor de los casos, sabrá sobre qué funciones existentes están enmascarados / sobrecargados por un paquete recién agregado. En el peor de los casos, no tendrás ni idea hasta que tu código se rompa.

Un par de ejemplos:

• intente cargar RMySQL y RSQLite, al mismo tiempo, no ir muy bien
• también RMongo sobrescribirá ciertas funciones de RMySQL
• forecast enmascara muchas cosas con respecto a las funciones relacionadas con ARIMA
• R. utils incluso máscaras la rutina base::parse

(No puedo recordar qué funciones en particular estaban causando los problemas, pero estoy dispuesto a buscarlo de nuevo si hay interés)

Sorprendentemente, esto no parece molestar a muchos programadores por ahí. Traté de aumentar el interés un par de veces en r-devel, sin ningún beneficio significativo.

Desventajas de usar el operador ::

1. El uso del operador :: podría dañar significativamente la eficiencia en ciertos contextos como Dominick Samperi señaló.
2. Cuando desarrolla su propio paquete, ni siquiera puede usar el operador :: a lo largo de su propio código, ya que su código aún no es un paquete real y, por lo tanto, tampoco hay espacio de nombres todavía. Así que tendría que atenerme inicialmente a la forma foo, construir, probar y luego volver a cambiar todo a namespace::foo. En realidad no.

Posibles soluciones para evitar estos problemas

1. Reasignar cada función de cada paquete a una variable que sigue ciertas convenciones de nomenclatura, por ejemplo, namespace..foo para evitar las ineficiencias asociadas con namespace::foo (lo describí una vez aquí). Ventajas: funciona. Desventajas: es torpe y doblas la memoria utilizada.
2. Simule un espacio de nombres al desarrollar su paquete. AFAIU, esto no es realmente posible, al menos me lo dijeron en ese entonces.
3. Hacer obligatorio para usar namespace::foo. En mi humilde opinión, eso sería lo mejor cosas que hacer. Claro, perderíamos algo de simplicidad, pero de nuevo el universo R ya no es simple (al menos no es tan simple como a principios de los 00).

¿Y qué pasa con las clases (formales)?

Aparte de los aspectos descritos anteriormente, :: way funciona bastante bien para funciones/métodos. Pero, ¿qué pasa con las definiciones de clase?

Tome el paquete TimeDate con su clase timeDate. Digamos que viene otro paquete que también tiene una clase timeDate. Me no veo cómo puedo declarar explícitamente que me gustaría una nueva instancia de class timeDate de cualquiera de los dos paquetes.

Algo como esto no funcionará:

new(timeDate::timeDate)
new("timeDate::timeDate")
new("timeDate", ns="timeDate")

Eso puede ser un gran problema a medida que más y más personas cambian a un estilo OOP para sus paquetes R, lo que lleva a muchas definiciones de clase. Si existe una forma de abordar explícitamente el espacio de nombres de una definición de clase, ¡apreciaría mucho un puntero!

Conclusión

Incluso aunque esto fue un poco largo, espero haber sido capaz de señalar el problema/pregunta central y que puedo crear más conciencia aquí.

Creo que devtoolsy mvbutils tienen algunos enfoques que podrían valer la pena difundir, pero estoy seguro de que hay más que decir.