[Rd] (no subject)

[Henrik Bengtsson]

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