[Rd] RFC: methods() and showMethods() {was "debug"}

[Martin Morgan]

Martin Maechler <maechler at stat.math.ethz.ch> writes:

>        (a new thread, on purpose)
>
>>>>>> "RobG" == Robert Gentleman <rgentlem at fhcrc.org>
>>>>>>     on Mon, 27 Jul 2009 16:55:50 -0700 writes:
>
>     RobG> Hi, I just committed a change to R-devel so that if
>     RobG> debug is called on an S3 generic function, all methods
>     RobG> will also automatically have debug turned on for them
>     RobG> (if they are dispatched to from the generic).
>
> very nice.
>
>     RobG>    I hope to be able to extend this to S4 and a few
>     RobG> other cases that are currently not being handled over
>     RobG> the next few weeks.
>
> that (S4) will be very useful for me, thank you in advance,
> Robert!
>
> A somewhat related issue:
> As many of the R-devel readers will know, there has been quite
> a nice ongoing effort to make S3 and S4 methods and classes more
> compatible.
> One issue here, notably for inexperienced programmeRs,
> is also the fact that
> methods(f) only tells about S3-methods for 'f',
> and showMethods(f) only mentions S4 ones.
> This is not at all design error, as indeed S3 and S4 dispatch is quite
> different (notably as the latter allows multiple dispatch and
> hence uses the nice concept of "signature"),
> used to be more incompatible and, indeed,  methods(f) *still*
> warns, often wrongly, if it finds that f is a (S4) generic function.
>
> As this is an RFC, let me just make a few more propositional
> points, and we (R core) will be happy to receive constructive
> feedback from outside the core team as well.
>
> Propositions / Ideas :
> [ Using the example of having Matrix: 
>   library(Matrix)
> ]
>
> 1) methods(f) should become a bit smarter when it sees that f is
>    an S4 generic,  and not say,  e.g., for  
>
>   >  methods(qr)
>   ...
>    'qr' is a formal generic function; S3 methods will not likely be found
>   ...
>
>   but rather at least "look" to see if there's an "ANY" method containing
>   UseMethod() (*1), 
>
> 2) and if there is, or maybe in any case, methods() should then
>    also call showMethods() to show the S4 methods;
>    or it would suggest the to user to call  'showMethods(..)'
>
> 3) showMethods(.) : It could/should  
>   a) look for S3 dispatch symptoms such as
>      UseMethod(.) in its "ANY" methods
>   b) call methods() in any case
>
>   and then possibly mention the result of methods() in any case,
>   *plus* ... that's probably the most difficult part ... 
>   warn if there are S3 methods {as per 'b)'} that seem not be
>   called at all {as per a)}, but that would also have to
>   consider .Primitive s with C internal (S3 and S4) dispatch.
>

Hi Martin --

A couple of thoughts on showMethods and methods, as a preamble.

1. It would be great if showMethods() returned an S4 object so that its
output could be used in a programmatic way.

2. If I

  library(Biobase); library(Matrix)
  showMethods(class="sparseMatrix")

I end up with entries like

  Function "selectSomeIndex":
    <not a generic function>
 
where selectSomeIndex is an unexported generic from Biobase. So it
would be helpful to clarify the output here, probably restricting
methods to those visible to the caller of showMethods.

3. showMethods allows the user to restrict the search to generics
defined in a particular name space, which can be useful.

4. showMethods has an includeDefs argument, which can also be useful
as a shortcut to constructing a second call (to getMethod or
selectMethod) with a potentially complicated argument list to specify
exactly the method to get.

5. methods() reports that 'Non-visible functions are asterisked' but
might provide additional information on how to access these
non-visible functions (e.g., getAnywhere, though here name spaces
might become important).

6. methods(print, "tukeyline") returning all print methods, but not
residuals.tukeyline. I think the behavior one wants is like
showMethods, the intersection of print methods relevant to class
tukeyline.

In terms of the original prompt about methods() functionality, it
would seem that looking for S4 methods, regardless of an ANY-method
would be 'good' since one use case is to understand object
dispatch. Point 1 makes us want to have an object to manipulate, and
then we must decide between S3 and S4 representation, and S4 probably
wins because of the greater flexibility. This might not be palatable to
all, perhaps leading to a smarter methods returning an S3 object and a
smarter showMethods returning an S4 object.

I wonder whether the functionality typically desired by users of
methods() is more analogous to selectMethod, i.e., find and display
the method that my object will be dispatched to, which is related to
4 and 6, above.

Martin

> As you see, these are partly concrete proposals, partly just
> ideas, asking for feedback, from you, experienced 
> programmeRs, ...
>
> Martin Maechler, ETH Zurich
>
>
> ---
> *1) as there will always be if the  S4 methods
>     have been setup properly and *after* the S3 ones.
>   This will typically be the case for situations when there are
>   old traditional S3 methods in "base R", and a package adds new
>   modern S4 methods.
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Martin Morgan
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109

Location: Arnold Building M1 B861
Phone: (206) 667-2793