В чем преимущество импорта в пространстве имен в R?

Механизм пространства имен R позволяет использовать функции export, которые затем видны пользователю. Кроме того, он позволяет выполнять функции import из других пакетов. В то время как преимущество экспорта очевидно, у меня больше проблем, понимающих преимущества импорта.

Одно из преимуществ, по-видимому, заключается в том, что можно использовать функции из других пакетов без привязки пакета и тем самым экономить память. Это показано в разделе 1.6.4 в руководстве по написанию R-расширений.

Однако в функции импорта должны быть другие преимущества. Особенно, раздел 1.6.6 (относится к классам S4) показывает namespace пакета 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)

Здесь есть импортированные функции, которые не являются ни классами S4, ни генериками (где было бы целесообразно использовать импорт также, как описано в примере в в этом разделе), но функции, такие как plot из пакета graphics, которые автоматически загружаются при запуске R.

Поэтому мой вопрос: в чем преимущество импорта таких функций, как plot, optim или qchisq?

Ответ 1

Если функция foo импортируется из панели пакетов, то она найдена независимо от того, что пользователь делает для своего пути поиска, например, путем присоединения пакета Baz, который также имеет функцию foo. Без пространства имен код пакета неожиданно обнаружил бы с помощью Baz::foo. Существуют также проблемы с эффективностью (foo найден сразу, а не после поиска по всем символам на пути поиска), но они могут быть тривиальными для большинства приложений. Точно так же importFrom является улучшением по сравнению с import из-за меньшего количества коллизий (или использования непреднамеренных функций) и более эффективного поиска.

С S4 (и S3) все может стать довольно сложным. Ненулезную функцию, такую как graphics::plot, можно повысить до общего (с setGeneric) в двух разных пакетах, и каждый родословный может иметь свой собственный набор методов. Автор пакета захочет быть точным, о чем plot generic, и, следовательно, какие методы рассылают таблицу, их классы и методы видят.

Вызов функции с помощью pkg::foo всегда разрешает предполагаемую функцию. Это требует, чтобы pkg был указан в поле Depends: файла DESCRIPTION (возможно, в Imports: но тогда это похоже на вводящую в заблуждение рекламу, чтобы не импортировать из pkg), загрязняя путь поиска пользователя. Он также включает в себя два символьных вида и вызов функции (::), и поэтому он менее эффективен. Ленькая и невнимательная часть меня также рассматривает использование :: как утомительного и подверженного ошибкам.

Пакет codetoolsBioC (через svn с именем пользователя и паролем readonly) может сгенерировать файл NAMESPACE из существующего пакета (или в по крайней мере, до недавних изменений в R-devel ввел NAMESPACE на пакеты без одного, я не пробовал codetoolsBioC на таком пакете).