showMethods isn't reporting inherited methods when it is first
called. The methods are there and after calling them, showMethods
gives the right output.
Here is an example (using R-devel r39647):
setClass("A", representation(x="numeric"),
prototype=list(x=1))
setClass("B", contains="A",
prototype=list(x=2))
setMethod("initialize", "A",
function(.Object) {
cat("In A's init\n")
.Object at x <- .Object at x + 1
.Object
})
setMethod("show", "A",
function(object) cat("An A like thing. x =", object at x, "\n"))
showMethods(classes="B") ## should give output, but doesn't
showMethods(classes="A")
aa <- new("A")
bb <- new("B")
aa
bb
## Now it will give output
showMethods(classes="B")
--
+ seth
Caching bug with showMethods?
5 messages · Seth Falcon, John Chambers
No, not a bug. Inherited methods are never cached until they are needed, for rather obvious efficiency reasons. See ?showMethods, under argument inherited= If what you were trying to do was find out what method would be called for class "B" without calling it, use selectMethod().
Seth Falcon wrote:
showMethods isn't reporting inherited methods when it is first
called. The methods are there and after calling them, showMethods
gives the right output.
Here is an example (using R-devel r39647):
setClass("A", representation(x="numeric"),
prototype=list(x=1))
setClass("B", contains="A",
prototype=list(x=2))
setMethod("initialize", "A",
function(.Object) {
cat("In A's init\n")
.Object at x <- .Object at x + 1
.Object
})
setMethod("show", "A",
function(object) cat("An A like thing. x =", object at x, "\n"))
showMethods(classes="B") ## should give output, but doesn't
showMethods(classes="A")
aa <- new("A")
bb <- new("B")
aa
bb
## Now it will give output
showMethods(classes="B")
--
+ seth
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
John Chambers <jmc at r-project.org> writes:
No, not a bug. Inherited methods are never cached until they are needed, for rather obvious efficiency reasons. See ?showMethods, under argument inherited=
ok, I missed the doc, which is quite clear about showMethods not doing what I wanted...
If what you were trying to do was find out what method would be called for class "B" without calling it, use selectMethod().
Yes, that is what I was trying to do. I thought showMethods was the preferred user interface to ask the system about what methods are available. When would one want the behavior of showMethods? Is it ever useful for a user to ask, "what are the methods that have been cached?". The problem with using selectMethod is one needs to know in advance the name of a generic. I would like to have a tool that lets me discover "what can be done" with an instance of a given class. showMethods is very close to being that tool, but the interaction with the method caching makes it confusing (until one has a solid understanding of the method caching, but IMHO this isn't something a user should need to know about if at all possible). Best, + seth -- Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center http://bioconductor.org
An embedded and charset-unspecified text was scrubbed... Name: not available Url: https://stat.ethz.ch/pipermail/r-devel/attachments/20061018/aabced44/attachment-0003.pl
John Chambers <jmc at r-project.org> writes:
If showMethods() were extended in this way but consistent with its behavior now, you would potentially get a mess (and do a lot of computation). Any method with "ANY" in any element of its signature qualifies (in particular, all default methods). And if you said inherited=TRUE, but did NOT give a limiting class---! I think the definition you want is to find all methods for which one of the superclasses of "B" appears explicitly in a signature, but excluding "ANY" from the superclasses used. That's quite a different (and longer) calculation than showMethods() does, but could indeed be useful.
Yes, I think excluding "ANY", but including "B" and any of its superclasses is what would be most useful. I realize it will take longer to compute, but I do think it would be a useful tool. + seth