Pecan: ネイティブR関数に基づく `PEcAn.logger`

主な理由は、ファイル内のメッセージを簡単に収集する方法でした。 それはメッセージ、警告、停止でどのように行われますか？

したがって、 PEcAn.loggerパッケージがロードされている場合、すべてのロギングは現在と同じように機能します。 ロギング機能を使用する必要がなくなっただけです。 事実上、私が提案しているのは次のとおりです。

# 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

したがって、ロガーレベル、出力ファイルなどを設定するためのすべての同じ機能が同じように機能するはずです。

ちなみに、基数Rのmessage 、 warning 、およびstopは、 sinkを介して選択的にリダイレクトできます。

名前が長すぎる場合：冗長なlogger.*部分を削除するエイリアスをエクスポートすることをお勧めします（例： PEcAn.logger::info() 。 それを超えるものはすべて、名前空間とlibrary呼び出しについての議論に戻ります。

expect_errorやsuppressMessagesのような関数での厄介さ：ここでの大きな根本的な違いは、PEcAn.loggerがRの正式な条件シグナリングメカニズムを使用しないため、どの関数でも使いにくいことです。 conditionが必要です。 PEcAn.loggerを条件を使用するように変更できる場合は、それを実行することをお勧めしますが、ここでの履歴にも精通していません- @ robkooperは、意図的な設計の選択/処理に必要なsignalConditionを回避していましたいくつかのリダイレクトの場合？

これについてもう少し考えた後、私のアプローチは意味がなく、実際には機能しないことに同意します。 個人的には、Rのデフォルト関数（ stop 、 warning 、 message ）を使用して、必要に応じてsink経由でリダイレクトすることをお勧めしますが、 PEcAn.loggerに固執する理由。 もう1つの可能性は、以前に提案されたfutile.loggerに切り替えることです（＃1362）。

それまでの間、私は@infotrophの提案の両方が好きです-より短いエイリアスとシグナリング条件を追加します。

もう1つの有望なアイデアは、次のような構文を提供するdebugmeパッケージです。

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

この問題は365日間開いており、アクティビティがないため、古くなっています。

＃1362の説明も参照してください