Wie funktioniert das PACKAGE-Argument für .Call?

Question

.Call scheint eher schlecht dokumentiert; ?.Call gibt eine Erklärung für das PACKAGE Argument:

PACKAGE: wenn geliefert, die Suche nach einer Zeichenkette .NAME auf das durch dieses Argument DLL beschränken (plus der konventionellen Erweiterung, ‚.so‘, ‚DLL‘ , ...).

Dieses Argument folgt ... und so kann der Name nicht abgekürzt werden.

Dies soll Sicherheit für Pakete hinzufügen, die mit diesem Argument sicherstellen können, dass kein anderes Paket ihre externen Symbole überschreiben kann, und beschleunigt auch die Suche (siehe 'Hinweis').

Und in der Anmerkung:

Wenn eine dieser Funktionen häufig verwendet werden soll, nicht angeben PACKAGE (die Suche auf eine einzelne DLL zu beschränken) oder .NAME als eines der nativen Symbol passieren Objekte. Die Suche nach Symbolen kann lange dauern, besonders wenn viele Namespaces geladen sind.

Sie können PACKAGE = "base" für Symbole sehen, die mit R verknüpft sind. Verwenden Sie dieses nicht in Ihrem eigenen Code: Solche Symbole sind nicht Teil der API und können ohne Warnung geändert werden.

verwendet, um akzeptiert zu werden (war aber nicht dokumentiert): es ist jetzt ein Fehler.

Aber es gibt keine Anwendungsbeispiele.

Es ist unklar, wie das PACKAGE Argument funktioniert. Zum Beispiel this Frage beantworten, dachte ich folgende gearbeitet haben sollte, aber es funktioniert nicht:

.Call(C_BinCount, x, breaks, TRUE, TRUE, PACKAGE = "graphics") 

Statt dies funktioniert:

.Call(graphics:::C_BinCount, x, breaks, TRUE, TRUE) 

Ist das einfach, weil C_BinCount ist unexported? Das heißt, wenn der interne Code hist.defaultPACKAGE = "graphics" hinzugefügt hätte, hätte dies funktioniert?

Dies scheint einfach, aber es ist sehr selten, die Verwendung dieses Arguments zu finden; keine der Quellen fand ich mehr geben, als die Rede vorbei (1, 2, 3, 4, 5) ... Beispiele hierfür eigentlich würde geschätzt arbeiten (auch wenn es in einem vorhandenen Paket gefunden werden unter Berufung auf nur Code)

(für die Selbsthaltung Zwecke, wenn Sie nicht wollen, zu Paste kopieren Code von der anderen Frage, hier sind x und breaks):

x = runif(100000000, 2.5, 2.6) 
nB <- 99 
delt <- 3/nB 
fuzz <- 1e-7 * c(-delt, rep.int(delt, nB)) 
breaks <- seq(0, 3, by = delt) + fuzz 

Answer 1

C_BinCount ist ein Objekt der Klasse „NativeSymbolInfo“, anstatt ein Zeichenfolge, die eine C-Level-Funktion nennt, also PACKAGE (die "th Die Suche nach einer Zeichenkette .NAME ") ist nicht relevant. C_BinCount wird ein Symbol durch seine Erwähnung in useDynLib() in dem Grafikpaket NAMESPACE gemacht.

Als 0-Symbol gilt C_BinCount 's Auflösung unterliegt den gleichen Regeln wie andere Symbole - es wird nicht aus dem NAMESPACE exportiert, also nur über graphics:::C_BinCount erreichbar. Und auch aus diesem Grund für eine robuste Code-Entwicklung tabu. Da der C-Einstiegspunkt als Symbol importiert wird, ist es nicht als Zeichenkette verfügbar, so .Call("C_BinCount", ...) wird nicht funktionieren.

Die Verwendung eines NativeSymbolInfo-Objekts teilt R mit, wo sich der C-Code befindet. Daher ist es nicht notwendig, dies über PACKAGE erneut zu tun. Die Wahl, das Symbol anstelle der Zeichenkette zu verwenden, wird vom Paketentwickler getroffen, und ich denke, dass dies im Allgemeinen als gute Praxis angesehen wird. Viele Pakete, die vor der Erfindung von NativeSymbolInfo entwickelt wurden, verwenden das PACKAGE-Argument, wenn ich den Bioconductor-Quellbaum grep, gibt es 4379 Zeilen mit .Call. * PACKAGE, z. B. here.

Weitere Informationen, einschließlich Beispiele, finden Sie im Abschnitt zum Schreiben von R-Erweiterungen 1.5.4.