On Tue, 23 Jun 2020, Bert Gunter wrote:
"Users don't get warned about overriding names in packages they've
loaded, because that would just be irritating."
All Duncan is saying is that you don't get a notification if you do
mean <- log
in the interpreter. If you attach a package that does this you would
get a notification (or an error if you configure your conflict
resolution options appropriately).
Best,
luke
Is that also true if the package or generic is imported by another that
they load; or is a dependency of a package they load? If so, I would not
call it "just irritating" because if silent, how would they know?
Bert Gunter
"The trouble with having an open mind is that people keep coming along and
sticking things into it."
-- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )
On Mon, Jun 22, 2020 at 5:58 PM Mark Leeds <marklee...@gmail.com> wrote:
Hi Duncan: I maintain dynlm and your example is the exact reason I've been
getting emails from people regarding
it not working correctly. I've been telling them to load dplyr by using
library(dplyr, exclude = c("filter", "lag"))
On Mon, Jun 22, 2020 at 7:57 PM Duncan Murdoch <murdoch.dun...@gmail.com>
wrote:
On 22/06/2020 3:48 p.m., Tom Wainwright wrote:
Yet another alternative is simply to prevent your second package from
overriding the previously defined generic. The basic problem is the
ease
with which R allows overriding prior generic definitions (one of those
bits
of bad behavior we in the USA used to call "a Bozo No-No"), which hides
all
the previous methods, as demonstrated by the following code:
plot(1:3)
plot <- function(x, ...) UseMethod("plot")
plot(1:3)
Error in UseMethod("plot") :
no applicable method for 'plot' applied to an object of class
"c('integer', 'numeric')"
rm(plot)
plot(1:3)
(Despite Murdoch's suggestion that overriding the generic SHOULD issue
a
warning, it doesn't seem to in R 4.0.1.)
Sure it does, if pkgA and pkgB both export the same name, then you get a
warning when you attach the second one. For example,
> library(MASS)
> library(dplyr)
Attaching package: ‘dplyr’
The following object is masked from ‘package:MASS’:
select
The following objects are masked from ‘package:stats’:
filter, lag
The following objects are masked from ‘package:base’:
intersect, setdiff, setequal, union
Users don't get warned about overriding names in packages they've
loaded, because that would just be irritating.
Duncan Murdoch
So, we might try protecting the generic definitions of "foo" in both
packages by enclosing them in something like:
tryCatch(invisible(methods("foo")), error = {foo <- function(x,...)
UseMethod("foo")}, finally=NULL)
There's probably a more elegant way to accomplish this. This relies on
"methods" returning an error if "foo" has no defined methods, so it is
not
redefined if their are previous methods. I haven't had time to try this
in
the two-package example, but it might work, although I'm not sure how
to
handle the Namespace declarations.
Tom Wainwright
On Mon, Jun 22, 2020 at 10:41 AM Bert Gunter <bgunter.4...@gmail.com>
wrote:
...
and just to add to the query, assume the author of pkg B did (does)
not
know of pkg A and so, for example, could (did) not import any of pkg
A's
content into B. Given that there are at the moment ~20,000 packages
out
there, this does not seem to be an unreasonable assumption. One may
even
further assume that the user may not know that (s)he has package B
loaded,
as it may be a dependency of another package that (s)he uses. I
certainly
don't keep track of all the dependencies of packages I use.
Under these assumptions, is there any more convenient alternative to
Wolfgang's pkgA:foo(x) explicit call under such assumptions? If pkgA
has a
long name, what might one do?
Bert Gunter
"The trouble with having an open mind is that people keep coming along
and
sticking things into it."
-- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )
On Mon, Jun 22, 2020 at 10:00 AM Viechtbauer, Wolfgang (SP) <
wolfgang.viechtba...@maastrichtuniversity.nl> wrote:
Hi All,
Let's say there are two packages pkgA and pkgB, both of which have a
generic function
foo <- function(x, ...)
UseMethod("foo")
and pkgA has a method for objects of class "A":
foo.A <- function(x, ...)
print(x)
and pkgB has a method for objects of class "B":
foo.B <- function(x, ...)
plot(x)
Both packages export foo and their method and declare their
respective
S3
methods, so:
export(foo)
export(foo.A)
S3method(foo, A)
in NAMESPACE of pkgA and
export(foo)
export(foo.B)
S3method(foo, B)
in NAMESPACE of pkgB.
If a user loads pkgA first and then pkgB, this fails:
library(pkgA)
library(pkgB)
x <- 1:4
class(x) <- "A"
foo(x)
Error in UseMethod("foo") :
no applicable method for 'foo' applied to an object of class "A"
and vice-versa. Of course, pkgA::foo(x) works. Aside from pkgA
importing
foo() or vice-versa, is there some other clever way to make this
work?
In
earlier versions of R (at least in 3.6.3), this used to work (i.e.,
the
generic foo() from pkgB would find method foo.A() and vice-versa),
but
not
since 4.0.0.
Best,
Wolfgang
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[[alternative HTML version deleted]]
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[[alternative HTML version deleted]]
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[[alternative HTML version deleted]]
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[[alternative HTML version deleted]]
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics and Fax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
