(no subject)

Henrik Bengtsson <hb <at> biostat.ucsf.edu> writes:

On Fri, Aug 30, 2013 at 11:51 AM, Henrik Bengtsson
<hb <at> biostat.ucsf.edu> wrote:

Hi.

[snip]

  Bump ... Henrik, did you ever post this as a request/wishlist at
https://bugs.r-project.org/bugzilla3/ ?  (I don't think so, I couldn't
find it there, but maybe I wasn't looking in the right place.) I
would be curious to know what the response was from R-Core, because
these kinds of warnings are starting to pop up in the nlme/lme4/
downstream package complex.  In particular,

VarCorr
fixef
lmList
ranef

are defined by nlme, imported and re-exported by lme4.  This doesn't
seem to make any trouble for lme4, but it does cause problems for
some of the downstream packages (such as GRRGI:
[broken URL for Gmane]
http://www.r-project.org/nosvn/R.check/
 r-devel-linux-x86_64-fedora-gcc/GRRGI-00check.html )

(Right now GRRGI uses a pretty crude import-all strategy:
import(nlme,lme4,...); exportPattern("."); which might be
tweaked, but I think the issue is still worth resolving.)

  In a perfect world, I guess some of these generics would be moved
upstream to a package that both nlme and lme4 could import from,
but that seems tricky to do without making fairly major architectural
changes.

  Ben Bolker

For the record, you're referring to R-devel thread 'Correct NAMESPACE
approach when writing an S3 method for a generic in another package'
started on Aug 24, 2013
[https://stat.ethz.ch/pipermail/r-devel/2013-August/067221.html].
Yes, it's closely related or possibly the same issue.  However, I do
not find it odd that the S3 generic function needs to be exported
from/available via the namespace.  Hence it needs to be export():ed by
at least one package/namespace.

The real issue is when two package needs to export a generic function
with the same name, e.g. foo().   If the two generic functions are
defined differently (e.g. different arguments/signatures), they will
be in conflict with each other.  If they are identical, this should
not be a problem, but here I might be wrong.  However, there is also
the special case where one package reexports the generic function from
another package, e.g. PkgB::foo() exports PkgA:foo().  In this case,
the object 'foo' does actually not existing in the name space of
package PkgB - instead it provides a "redirect" to it, e.g.

PkgA::foo

function (...)
UseMethod("foo")
<environment: namespace:PkgA>

PkgB::foo

function (...)
UseMethod("foo")
<environment: namespace:PkgA>

exists("foo", envir=getNamespace("PkgB"), inherits=FALSE)

[1] FALSE

exists("foo", envir=getNamespace("PkgB"), inherits=TRUE)

[1] TRUE

identical(PkgB::foo, PkgA::foo)

[1] TRUE


The warning on "replacing previous import by 'PkgA::foo' when loading
'PkgC'" that occurs due to import(PkgA, PkgB) is generated in
base::namespaceImportFrom()
[http://svn.r-project.org/R/trunk/src/library/base/R/namespace.R]

Note how there is already code for avoiding "false" warnings on S4
generic function.  This is what we'd like to have also for S3 generic
functions, but it's much harder to test for such since they're not
formally defined.  However, I'd argue that it is safe to skip the
warning *when the variable to be imported does not actually exist in
the package being imported* (e.g. when just rexported), i.e.