2015-01-11 13 views
7

Ich habe ein Paket mit S4-Klassen geschrieben und möchte die Funktionen rbind, cbind mit diesen definierten Klassen verwenden.Korrekte Verwendung von cbind, rbind mit s4-Klassen im Paket

Da es scheint nicht möglich zu sein, zu definieren rbind und cbind direkt als S4 Methoden I definiert rbind2 und cbind2 statt:

setMethod("rbind2", signature(x="ClassA", y = "ANY"), 
    function(x, y) { 
     # Do stuff ... 
}) 

setMethod("cbind2", signature(x="ClassA", y = "ANY"), 
    function(x, y) { 
     # Do stuff ... 
}) 

Von ?cbind2 habe ich gelernt, dass diese Funktionen aktiviert werden müssen methods:::bind_activation mit ersetzen rbind und cbind von der Basis.

enthalten ich den Anruf in der Paketdatei R/zzz.R die .onLoad Funktion:

.onLoad <- function(...) { 
    # Bind activation of cbind(2) and rbind(2) for S4 classes 
    methods:::bind_activation(TRUE) 
} 

Dies funktioniert wie erwartet. Überprüfen Sie jedoch läuft R CMD Ich bin jetzt die folgende Notiz bekommen, da ich eine unexported Funktion in Methoden verwenden:

* checking dependencies in R code ... NOTE 
Unexported object imported by a ':::' call: 'methods:::bind_activation' 
    See the note in ?`:::` about the use of this operator. 

Wie kann ich den Hinweises loswerden und was ist der richtige Weg, die Methoden zu definieren cbind und rbind für S4-Klassen in einem Paket?

+0

Würde es Ihnen etwas ausmachen, die Klassendefinitionen (z. B. 'setClass (" ClassA ", ...)') einiger der S4-Klassen, die Sie 'rbind'- und' cbind'-Methoden hinzufügen möchten, zu verwenden? Es würde es einfacher machen, eine Lösung für Ihr Problem zu finden. – nrussell

+1

Die Klassendefinitionen sollten in diesem Fall keine Rolle spielen, da es nur um die Methodenauswahl/-verteilung geht. Sie können also jede Definition wie setClass ("ClassA", Repräsentation (a = "numerisch")) verwenden. – user625626

+0

Könnten Sie vielleicht auch erklären, warum "* ... es nicht möglich scheint, rbind und cbind direkt als S4-Methoden zu definieren ... *" - fügen Sie vielleicht Ihren Code hinzu, um dies zu implementieren? – nrussell

Antwort

4

Ich denke im Grunde ist die cBind Hilfeseite im Matrix-Paket historisch korrekt, aber nicht in letzter Zeit. Hier ist eine Klasse

.A = setClass("A", representation(x="numeric")) 

Es gibt keine generisch, so erstellen, Dispatching auf dem '...' Argumente (siehe ?setMethod und ?dotsMethods)

getGeneric("cbind") 
## NULL 
setGeneric("cbind", signature="...") 
## Creating a new generic function for 'cbind' in the global environment 

Dann ein Verfahren implementieren

setMethod("cbind", "A", function(..., deparse.level=1) "cbind,A-method") 
## [1] "cbind" 

Und schließlich verwenden Sie es

> cbind(.A(), .A()) 
[1] "cbind,A-method" 

Das ist in Ordnung, solange die '...' Argumente die gleiche (möglicherweise abgeleitete) Klasse sind, was oft gut genug ist.

> cbind(.A(), integer()) 
    [,1] 
[1,] ? 

Ich glaube, dass bind_activation() globale Auswirkungen hat, nicht nur beim Versand in Ihrem Paket; Es sollte vermieden werden (es wird zum Beispiel nicht mehr im Matrix-Paket verwendet).

Außerdem glaube ich, dass diese

in R-devel aktualisiert wurde

r67699 | Lawrence | 2015-02-01 10:13:23 -0800 (So, 01 Feb 2015) | 4 Linien

cbind/rbind nun rekursiv cbind2 (rbind2), wenn mindestens ein Argument ist ein Objekt S4 und S3 Dispatch nicht übertragen; Beachten Sie auch S4 Vererbung während S3-Versand in den * Bind-Funktionen.

Verwandte Themen