Hi, it appears that you've lost the original thread R-devel thread '"False" warning on "replacing previous import" when re-exporting identical object' started on 2013-08-29 [https://stat.ethz.ch/pipermail/r-devel/2013-August/067321.html].
(and forgot the subject line), so in order to not start yet another thread I'll close this one and reply/cc you there. /Henrik On Sat, Sep 21, 2013 at 9:44 AM, Ben Bolker <bbol...@gmail.com> wrote: > 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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
