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. > > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
