I think I understand what you're looking for, but it's nontrivial and should really be another function, like findAllMethods(class, functions)
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. Seth Falcon wrote: > John Chambers <[EMAIL PROTECTED]> 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 > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
