Pecan: Basez `PEcAn.logger` sur des fonctions R natives

La raison principale était un moyen de collecter facilement des messages dans un fichier. Comment cela se ferait-il avec un message, un avertissement et un arrêt ?

Ainsi, toute la journalisation fonctionnerait de la même manière que si le package PEcAn.logger était chargé. C'est juste que l'utilisation des fonctions de journalisation n'est plus nécessaire. Effectivement, ce que je propose c'est :

# 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

Ainsi, toutes les mêmes fonctions de réglage du niveau d'enregistrement, du fichier de sortie, etc. devraient fonctionner de la même manière.

En passant, les R de base message , warning et stop peuvent être redirigés de manière sélective via sink .

Les noms étant trop longs : je préférerais exporter des alias qui suppriment la partie redondante logger.* , par exemple PEcAn.logger::info() . Tout ce qui va au-delà revient dans l'argument concernant les espaces de noms par rapport aux appels library .

Re maladresse avec des fonctions comme expect_error ou suppressMessages : La grande différence sous-jacente ici est que PEcAn.logger n'utilise pas le mécanisme formel de signalisation de condition de R, et est donc difficile à utiliser avec n'importe quelle fonction qui attend un condition . Si PEcAn.logger peut être réorganisé pour utiliser des conditions, je préférerais le faire, mais je ne connais pas non plus l'histoire ici - @robkooper , évitait signalCondition un choix de conception intentionnel / nécessaire pour gérer des cas de redirection ?

Après y avoir réfléchi un peu plus, je suis d'accord que mon approche n'a pas de sens et ne fonctionnerait pas réellement. Personnellement, je préférerais probablement utiliser les fonctions par défaut de R ( stop , warning , message ), en les redirigeant via sink si nécessaire, mais je peux voir la raison pour s'en tenir à PEcAn.logger . Une autre possibilité est de passer à futile.logger , ce qui a été suggéré précédemment (#1362).

En attendant, j'aime les deux suggestions de @infotroph -- ajouter des alias plus courts et des conditions de signalisation.

Une autre idée prometteuse est le package debugme , qui fournit une syntaxe comme celle-ci :

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)
}

Ce problème est obsolète car il a été ouvert pendant 365 jours sans activité.

Voir aussi la discussion dans #1362