[Rd] (no subject)

[Ben Bolker]

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.
> >