Best Practice zum Definieren von S3-Methoden mit unterschiedlichen Argumenten

Question

Ich bin dabei, ein Standard-S3-Versandsystem zu meinem Paket hinzuzufügen (OneR), wo ich eine Methode für Datenrahmen und eine für Formeln habe.

Das Problem, das ich habe, ist, dass ich unterschiedliche Argumente für beide Methoden habe. Ich brauche das Argument data beim Aufrufen der Datenrahmenmethode nicht, da die Daten bereits im Argument x vorhanden sind. data wird nur beim Aufruf der Formel-Methode benötigt.

Ich habe es wie folgt aus:

Usage 

optbin(x, data, method = c("logreg", "infogain", "naive"), na.omit = TRUE) 

## S3 method for class 'formula' 
optbin(x, data, method = c("logreg", "infogain", "naive"), 
    na.omit = TRUE) 

## S3 method for class 'data.frame' 
optbin(x, data = x, method = c("logreg", "infogain", 
    "naive"), na.omit = TRUE) 


Arguments 

x either a formula or a data frame with the last column containing the target variable. 
data data frame which contains the data, only needed when using the formula interface because otherwise 'x' will already contain the data. 
method character string specifying the method for optimal binning, see 'Details'; can be abbreviated. 
na.omit logical value whether instances with missing values should be removed. 

Ich dachte zuerst, dass ich nur das data Argument in dem Datenrahmen Verfahren auslassen, aber wenn das Paket mir eine Warnung überprüft, weil es in den UseMethod ist Funktion ... wenn ich es draußen lasse, bekomme ich eine weitere Warnung wegen der Inkonsistenzen zwischen den Methoden. Ich versuchte auch ..., aber ich bekomme auch Warnungen dort außer ich muss es dokumentieren, das Benutzer mehr verwirren würde, als es helfen würde.

Aber ich finde auch nicht meine Lösung oben ideal wegen der data = x Argument in der Datenrahmen-Methode. Es könnte Menschen verwirren und ist eine potentielle Fehlerquelle.

Meine Frage
Was ist der beste Weg, um die Situation zu lösen, das heißt, wenn Sie zwei Methoden mit verschiedenen Argumenten?

Answer 1

Der übliche Ansatz besteht darin, ein Generikum ohne zusätzliche Argumente außer ... zu haben. Jede Schnittstellenmethode sollte eine zugrunde liegende default-Methode aufrufen, die die tatsächliche Modellanpassung implementiert.

optbin <- function(x, ...) 
UseMethod("optbin") 

optbin.formula <- function(formula, data, method, na.omit, arg1, arg2, ...) 
{ 
    ... 
    optbin.default(x, y, arg1, arg2) 
} 

optbin.data.frame <- function(data, method, na.omit, arg1, arg2, ...) 
{ 
    ... 
    optbin.default(x, y, arg1, arg2) 
} 

optbin.default <- function(x, y, arg1, arg2) 
{ ... } 

Siehe zum Beispiel, wie die Pakete nnet und MASS Methoden für Formeln handhaben.