From sfalcon at fhcrc.org  Fri Oct 13 16:27:13 2006
From: sfalcon at fhcrc.org (Seth Falcon)
Date: Fri, 13 Oct 2006 07:27:13 -0700
Subject: [Rd] getMethods() not finding all methods
In-Reply-To: <452F8BBD.3020401@r-project.org> (John Chambers's message of "Fri,
	13 Oct 2006 08:51:09 -0400")
References: <0BE438149FF2254DB4199E2682C8DFEB01D555DF@crcmail1.BCCRC.CA>
	<m2wt75m54e.fsf@ziti.local>
	<0BE438149FF2254DB4199E2682C8DFEB0235F920@crcmail1.BCCRC.CA>
	<452F8BBD.3020401@r-project.org>
Message-ID: <m2lknkl29q.fsf@ziti.local>

John Chambers <jmc at r-project.org> writes:
> Yes, that's why showMethods() has the option includeDefs=TRUE to
> include the definitions.  There are other options to look at multiple
> functions or specific classes.  Look at ?showMethods

A feature request: it would be useful in the context of attempting to
build documentation helper tools to have a return value that was
more structured than what printTo=FALSE provides.

> And no, it's not a bug in getMethods(), which was never intended for
> human-readable output, but a side-effect of the changes for faster
> caching and dispatch in 2.4.0.  With the use of environments in place
> of the methods list objects (returned by getMethods()), getMethods()
> will probably be deprecated in the next version.

I was expecting a different result based on the first sentence in the
doc describing getMethods:

     The function 'getMethods' returns all the methods for a particular
     generic (in the form of a generic function with the methods
     information in its environment).

Hence, it surprises me that not all methods are returned.  Reading on
I now see:

     ... is not intended to be called directly.

So I guess I got what I deserve ;-)

+ seth




[Rd] getMethods() not finding all methods
Seth Falcon