Pecan: Base `PEcAn.logger` en funciones R nativas

La razón principal fue que era una forma de recopilar mensajes en un archivo fácilmente. ¿Cómo se haría eso con mensaje, advertencia y parada?

Por lo tanto, todo el registro funcionaría de la misma manera que ahora si se carga el paquete PEcAn.logger . Es solo que ya no es necesario usar las funciones de registro. Efectivamente, lo que propongo es:

# These call the default R functions
message("hello")
warning("whoops")
stop("whoah")

library(PEcAn.logger)
# By loading the logger package, the functions become masked so
message("hello")      # This actually calls `PEcAn.logger::logger.info
warning("whoops")   # This calls `PEcAn.logger::logger.warn
stop("error")      # This calls `PEcAn.logger::logger.severe

Por lo tanto, todas las mismas funciones para configurar el nivel del registrador, el archivo de salida, etc. deberían funcionar de la misma manera.

En una nota al margen, las R base message , warning y stop se pueden redirigir selectivamente a través sink .

Los nombres son demasiado largos: preferiría exportar alias que eliminen la parte redundante logger.* , por ejemplo, PEcAn.logger::info() . Cualquier cosa más allá de eso vuelve al argumento sobre los espacios de nombres frente a las llamadas library .

Re incomodidad con funciones como expect_error o suppressMessages : la gran diferencia subyacente aquí es que PEcAn.logger no usa el mecanismo de señalización de condición formal de R y, por lo tanto, es incómodo de usar con cualquier función que espera un condition . Si PEcAn.logger se puede renovar para usar condiciones, preferiría hacerlo, pero tampoco estoy familiarizado con el historial aquí: @robkooper , estaba evitando signalCondition una elección de diseño intencional / necesaria para manejar algunos casos de redirección?

Después de pensar en esto un poco más, estoy de acuerdo en que mi enfoque no tiene sentido y en realidad no funcionaría. Personalmente, probablemente preferiría usar las funciones predeterminadas de R ( stop , warning , message ), redirigiéndolas a través sink cuando sea necesario, pero puedo ver la justificación para quedarse con PEcAn.logger . Otra posibilidad es cambiar a futile.logger , que se sugirió anteriormente (#1362).

Mientras tanto, me gustan las dos sugerencias de @infotroph : agregar alias más cortos y condiciones de señalización.

Otra idea prometedora es el paquete debugme , que proporciona una sintaxis como esta:

f <- function(a, b = 3) {
  c <- a + b
  d <- a * b
  e <- a ^ b
  "!DEBUG arguments are a = `a` and b = `b`"
  c(c, d, e)
}

Este problema está obsoleto porque ha estado abierto los 365 días sin actividad.

Ver también discusión en #1362