On Mon, Jun 30, 2014 at 6:19 AM, Duncan Murdoch
wrote:
> On 30/06/2014 8:51 AM, Michael Lawrence wrote:
>
>> I think it's generally nice to be able to compute on the network of
>> imported and exported symbols, and exportFrom() preserves the information
>> that a symbol has been forwarded. But le
On 30/06/2014 8:51 AM, Michael Lawrence wrote:
I think it's generally nice to be able to compute on the network of
imported and exported symbols, and exportFrom() preserves the
information that a symbol has been forwarded. But let's focus on the
use case of documenting the symbol.
First, from
I think it's generally nice to be able to compute on the network of
imported and exported symbols, and exportFrom() preserves the information
that a symbol has been forwarded. But let's focus on the use case of
documenting the symbol.
First, from the user perspective: my understanding (without tes
On 29/06/2014, 3:07 PM, Michael Lawrence wrote:
> While the change to the symbol lookup is generally useful (e.g., for
> finding S4 methods that become available whenever a package is loaded),
> it seems that we ultimately want a mechanism by which a package
> namespace can formally declare that it
While the change to the symbol lookup is generally useful (e.g., for
finding S4 methods that become available whenever a package is loaded), it
seems that we ultimately want a mechanism by which a package namespace can
formally declare that it is re-exporting a symbol from some package. Then,
for e
Hi Duncan,
Again, thanks a lot for making this change (help requests are tried
over all loaded instead of attached packages):
https://github.com/wch/r-source/commit/21d2f7430b4 This makes what I
proposed last time possible now: if pkg B imports FUN from A and
re-exports it, ?FUN will work after B
Plummer
Cc: winstoncha...@gmail.com; r-devel@r-project.org
Subject: Re: [Rd] R CMD check warning with S3 method
> When you provide a method for a generic function imported from another
> package then the generic must be on the search path. Otherwise if a user
> types "filter" the dispatc
> When you provide a method for a generic function imported from another
> package then the generic must be on the search path. Otherwise if a user
> types "filter" the dispatch to "filter.test" will never occur.
Right, and this is as desired. If dplyr is not explicitly loaded by
the user, filter.
On Fri, 2014-06-20 at 01:34 -0500, Yihui Xie wrote:
> but note that you will have to document it even if it is a function
> imported from another package...
Let's not go round in circles. I already pointed this out in my earlier
reply to Winston. It has been snipped from the thread history so I'l
On 20/06/2014, 8:34 AM, Yihui Xie wrote:
> but note that you will have to document it even if it is a function
> imported from another package... Perhaps help() should be intelligent
> enough to link the documentation of `FUN` from package A for package B
> when B imports `FUN` from A, and exports
but note that you will have to document it even if it is a function
imported from another package... Perhaps help() should be intelligent
enough to link the documentation of `FUN` from package A for package B
when B imports `FUN` from A, and exports it in B's NAMESPACE. The
package name of A may be
On Thu, Jun 19, 2014 at 3:15 PM, Martyn Plummer wrote:
> Export filter in the NAMESPACE file *without copying it* in the R source
> code.
>
>
Ah, it works! Thank you!
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
Export filter in the NAMESPACE file *without copying it* in the R source code.
From: Winston Chang [winstoncha...@gmail.com]
Sent: 19 June 2014 21:28
To: Martyn Plummer
Cc: r-devel@r-project.org
Subject: Re: [Rd] R CMD check warning with S3 method
Oh, I forgot to
Oh, I forgot to mention I tried a few other variations:
=
Re-export dplyr::filter:
filter <- dplyr::filter
NAMESPACE has:
S3method(filter,test)
export(filter)
importFrom(dplyr,filter)
Then the filter.test method from s3methodtest doesn't seem to get
registered properly:
When you provide a method for a generic function imported from another
package then the generic must be on the search path. Otherwise if a user
types "filter" the dispatch to "filter.test" will never occur.
What is happening here is worse because "filter" is a non-generic
function in the stats pac
I forgot to add this - here's the warning:
* checking S3 generic/method consistency ... WARNING
Warning: declared S3 method 'filter.test' not found
See section 'Generic functions and methods' of the 'Writing R
Extensions' manual.
On Tue, Jun 17, 2014 at 2:21 PM, Winston Chang wrote:
> I'm getti
I'm getting an R CMD check warning with a package (call it package A)
that defines an S3 method but not the generic. The generic is defined
in another package (package B). Package A imports the S3 generic from
B. And there's one additional detail: the generic overrides a function
in the stats packa
17 matches
Mail list logo
