The bug should be fixed in r-devel and 2.13 patched, as of svn rev. 56090.
John
On 6/7/11 12:42 AM, Iago Mosqueira wrote:
On Mon, Jun 6, 2011 at 11:28 PM, John Chambers<j...@r-project.org> wrote:
This is a bug, medium-subtle, but also raises an interesting software design
point.
The Bug:
Nothing specific about "ANY" and "missing", but the issue is whether the
method was inherited (the "ANY" case) or defined directly (the "missing"
case).
Generic functions keep a cached table of dispatched methods, to save
determining inherited methods repeatedly for calls with the same signature.
When pkg B is loaded, the inherited methods are reset, but apparently the
directly defined ones were not (but should have been if pkg B overrides the
method).
It's interesting that this bug seems not to have been reported before, which
leads to:
The Software Design Point:
When a package (B) extends the class/method software in another package (A),
typically B adds new classes and perhaps new generic functions with methods
for previous classes in A as well as classes in B. It might also extend the
behavior for classes in A to other generic functions.
What is less usual is to directly override an existing method for a class
that belongs to A. Notice that there can be side-effects, such as behavior
of examples or tests in package A depending on whether B has been loaded or
not. And objects created entirely from A could have their computations
change after B was loaded.
Nothing at all illegal here, and we'll make it work. But a more predictable
implementation for most applications would, say, define a new class in B
that extended the class in A. In your example (very helpful, by the way)
one might have a class "mynumB", perhaps with the same slots as "mynum" but
with modified behavior.
If you want to keep the current implementation, though, a workaround until
the bug is fixed would be something like:
setMethod("plot", c("mynum", "missing"), getMethod("plot", c("mynum",
"missing")))
executed after B is attached (I think it could be in the .onLoad function
for B, but have not tested that).
John
Many thanks for the very complete explanation. We are using this
mechanism to provide ggplot2-based plot for some classes, to
substitute the initial lattice-based ones, so the effects are limited
to visual output and not results of computation, but it is good you
reminded me of the possible side effects of this strategy. Is maybe a
warning during R CMD check appropriate here?
Adding the call to setMethod(..., getMethod()) did not work if placed
inside .onLoad, and in fact had the effect of getMethod() now
returning the Apkg method after Bpkg was loaded.
Running the line after Bpkg has loaded did sort it out. What would
then be the best way of adding this command to the pkg loading
process? I have also tried adding it to a zzz.R file on iuts own but
that did not work, I still need to re-run it after loading has
finished.
Many thanks,
Iago
On 6/6/11 4:11 AM, Iago Mosqueira wrote:
On Wed, Jun 1, 2011 at 6:04 PM, Martin Morgan<mtmor...@fhcrc.org> wrote:
On 06/01/2011 04:39 AM, Iago Mosqueira wrote:
Dear all,
I am experiencing some problems with S4 method overloading. I have
defined a generic for graphics:plot, using
setGeneric("plot", useAsDefault = plot)
and with
importFrom('graphics', 'plot') and
exportMethods('plot') in the NAMESPACE file of pkg A.
I'd guess you were creating two generics (explicitly in pkgA, implicitly
in
pkgB). Maybe
export(plot)
in NAMESPACE of pkg A,
importFrom('pkgA', plot)
exportMethods(plot)
in pkg B. Feel free to post to the list if that's helpful.
Martin
I then proceed to define a method for signature c('myS4class',
'missing'). This works as expected: selectMethod('plot',
c('myS4class', 'missing')) returns the newly defined method, and the
method gets called when invoked.
Another pkg, B, wishes to overload this and redefines the method for
the same signature. A method is defined for c('myS4class', 'missing'),
and exported on the NAMESPACE. The new method is shown by
selectMethod() after pkg B has been loaded, but a call to
plot(anobjectofmyS4class)
comes up with the result of running the first method, from pkg A. I
have tried importing 'plot' in B's NAMESPACE from both graphics or A,
but the end result is the same.
Package B does the same thing for a method created by pkg A, myMethod,
and that works fine.
Any pointers or where this might be going wrong? How is it that a
different method than the one shown by selectMethod() is being run?
Something to do with the 'missing' part of the signature?
Many thanks,
Iago Mosqueira
Dear all,
I have tried Martin's suggestion, but the problem persists. It seems
to be related to having 'missing' in the signature, as doing the same
kind of overloading for c('myclass', 'ANY') work as expected.
I am attaching 2 simple packages where I attempt this repeated
overloading of plot for the same class. Script below, also found in
Bpkg/tests.test.R, shows what I have encountered so far:
plot('myclass', 'ANY') can be re-overloaded, but plot('myclass',
'missing') cannot in the same way. If I run
trace("plot", browser, exit=browser, signature = c("mynum", "missing"))
the new method is actually called.
Any hint on what I am doing wrong or where to look for an explanation
will be much appreciated.
Best regards,
Iago Mosqueira
______________________________________________
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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
