Jakie są korzyści z importu w przestrzeni nazw w R?

Question

Jakie są korzyści z importu w przestrzeni nazw w R?

Mechanizm przestrzeni nazw r pozwala na export funkcje, które następnie są widoczne dla użytkownika. Ponadto pozwala na import funkcje z innych pakietów. Podczas gdy korzyści płynące z eksportu są oczywiste, mam więcej problemów ze zrozumieniem korzyści płynących z importu.

Jedną z korzyści wydaje się być to, że można używać funkcji z innych pakietów bez dołączania pakietu i tym samym oszczędzania pamięci. Jest to przykład w sekcji 1.6.4 w pisaniu rozszerzeń R manual .

Muszą być jednak inne korzyści z funkcji importu. W szczególności sekcja 1.6.6 (która dotyczy klas S4) pokazuje namespace pakietu stats4:

 export(mle)
 importFrom("graphics", plot)
 importFrom("stats", optim, qchisq)
 ## For these, we define methods or (AIC, BIC, nobs) an implicit generic:
 importFrom("stats", AIC, BIC, coef, confint, logLik, nobs, profile,
            update, vcov)
 exportClasses(mle, profile.mle, summary.mle)
 ## All methods for imported generics:
 exportMethods(coef, confint, logLik, plot, profile, summary, show, update, vcov)
 ## implicit generics which do not have any methods here
 export(AIC, BIC, nobs)

Tutaj są zaimportowane funkcje, które nie są ani klasami S4, ani generikami (gdzie sensownym byłoby również użycie import, co zostało udokumentowane w przykładzie w tej sekcji ), Ale funkcje takie jak plot z graphics pakietu, które są ładowane automatycznie, gdy R zaczyna.

Dlatego moje pytanie brzmi, Jakie są korzyści z importowania funkcji takich jak plot, optim albo qchisq?

29

namespaces r package

Author: Henrik, 2011-09-02

Source

1 answers

score 23 · Accepted Answer

Jeśli funkcja foo zostanie zaimportowana z package Bar, to zostanie znaleziona niezależnie od tego, co użytkownik zrobi ze ścieżką wyszukiwania, np. poprzez dołączenie pakietu Baz, który ma również funkcję foo. Bez spacji nazw kod pakietu nagle znalazłby się przy użyciu Baz::foo. Istnieją również problemy z wydajnością (foo znajduje się natychmiast, a nie po przeszukiwaniu wszystkich symboli na ścieżce wyszukiwania), ale są one prawdopodobnie trywialne dla większości aplikacji. W ten sam sposób importFrom jest poprawa w stosunku do import z powodu mniejszej liczby kolizji (lub wykorzystania niezamierzonych funkcji) i bardziej efektywnego wyszukiwania.

Z S4 (i S3) sprawy mogą się skomplikować. Nie-generyczna funkcja, taka jak graphics::plot, może być promowana do generycznej (z setGeneric) w dwóch różnych pakietach, a każdy generyczny może mieć dołączony własny zestaw metod. Autor pakietu będzie chciał dokładnie określić, która plot jest generyczna, a co za tym idzie, które metody wyświetlają tabelę, ich klasy i metody.

Wywołanie funkcja z pkg::foo zawsze rozwiązuje się do zamierzonej funkcji. Wymaga to, aby pkg był wymieniony w polu Depends: pliku opisu (może w import: , ale wtedy wydaje się, że reklama wprowadzająca w błąd nie importuje z pkg), zanieczyszczając ścieżkę wyszukiwania użytkownika. Obejmuje również dwa spojrzenia symboli i wywołanie funkcji (::), a więc jest mniej wydajne. Leniwa i brak dbałości o szczegóły część mnie również postrzega używanie :: jako żmudne i podatne na błędy.

Pakiet codetoolsBioC (poprzez svn z nazwą użytkownika i hasłem readonly) może wygenerować plik przestrzeni nazw z istniejącego pakietu (lub przynajmniej zanim ostatnie zmiany w R-devel wprowadziły przestrzeń nazw na pakietach bez nich; nie próbowałem codetoolsBioC na takim pakiecie).