Jakie są zalety importu w przestrzeni nazw w R?

Question

Mechanizm przestrzeni nazw R umożliwia dostęp do funkcji export, które następnie są widoczne dla użytkownika. Ponadto pozwala na funkcje import z innych pakietów. Podczas gdy korzyść z eksportu jest oczywista, mam większe problemy ze zrozumieniem korzyści z importu.

Jedna z korzyści polega na tym, że można używać funkcji z innych pakietów bez dołączania pakietu, a tym samym do oszczędzania pamięci. Jest to zilustrowane w sekcji 1.6.4 in the writing R extensions manual.

Jednak muszą istnieć inne korzyści z funkcji importu. Zwłaszcza, section 1.6.6 (that deals with S4 classes) pokazano ten 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 istnieją funkcje importowane, które nie są ani klasy ani rodzajowych S4 (gdzie byłoby sensu używać importu, jak również, co zostało udokumentowane w przykładzie w that section) , ale działa jak plot z pakietu graphics, które są automatycznie ładowane po uruchomieniu R.

Dlatego moje pytanie brzmi: jaka jest korzyść z importowania funkcji takich jak plot, optim lub qchisq?

Answer 1

Jeśli funkcja foo jest importowana z paska pakietu, to jest ona znaleziona niezależnie od tego, co użytkownik robi ze swoją ścieżką wyszukiwania, np. Przez dołączenie pakietu Baz, który również ma funkcję foo. Bez przestrzeni nazw kod pakietu nagle znalazłby się przy użyciu Baz::foo. Występują również problemy z wydajnością (foo znajduje się natychmiast, a nie po przeszukaniu wszystkich symboli na ścieżce wyszukiwania), ale w przypadku większości aplikacji mogą one być trywialne. W ten sam sposób, importFrom jest ulepszeniem w stosunku do import z powodu mniejszej liczby kolizji (lub użycia niezamierzonych funkcji) i bardziej wydajnego wyszukiwania.

Rzeczy S4 (i S3) mogą być dość skomplikowane. Nietypowa funkcja, taka jak graphics::plot, może być promowana do postaci ogólnej (z setGeneric) w dwóch różnych pakietach, a każdy rodzajowy może mieć przypisany własny zestaw metod. Autor pakietu będzie chciał precyzyjnie określić, która z tych metod powinna zawierać tabelę, ich klasy i metody.

Wywołanie funkcji z pkg::foo zawsze rozwiązuje zamierzoną funkcję. Wymaga, aby pkg był wymieniony w polu Depends: w pliku DESCRIPTION (może w Imports: ale wydaje się, że reklamy wprowadzające w błąd nie importują z pkg), zanieczyszczając ścieżkę wyszukiwania użytkownika. Obejmuje również dwa wyszukiwania symboli i wywołanie funkcji (::), a więc jest mniej wydajne. Leniwa i nie zwracająca uwagi na szczegóły część mnie także widzi użycie :: jako uciążliwego i podatnego na błędy.

Pakiet codetoolsBioC (przez svn z nazwy i hasła readonly) może wygenerować plik nazw z istniejącego pakiet (lub przynajmniej może wcześniej ostatnie zmiany R-devel wprowadzono nazw na pakietach bez nich, nie ma wypróbował codetoolsBioC na takim pakiecie).