Seth Falcon wrote: > John Chambers <[EMAIL PROTECTED]> 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. > Maybe, but the question is what.
I agree that the printTo=FALSE is largely useless. It's a relic from some initial design attempts to make the output more flexible. If you look at all the options to showMethods(), with multiple functions, classes, and optional definitions, a single structure for all of them may be pretty clumsy. It would help to know what people plan to do with such an object. >> 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 ;-) > The documentation needs some clarification, for 2.4.1 > + seth > > ______________________________________________ > 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
