The convention for documenting S4 methods provides a general way to get
the documentation for a method, given the name of the function and the
name(s) of the classes in the signature:
method?"FUN,CLASS1,CLASS2,..."
where FUN is the name of the function and CLASS1, etc. are the names of
the classes in the method signature.
For example,
> method?"show,traceable"
gives the documentation for the show() method for class "traceable".
For a truly excruciating example,
> method?"[,sparseMatrix,index,missing,logical"
gives the documentation for the corresponding method in the Matrix
package ("I'm not making this up you know", as Anna Russell would say).
So the mechanism is obscure and unfriendly, to say the least, but it is
general.
It would be nice to have a decent user interface. Actually, by
combining the code for showMethods() and the mechanism above, one could
have a fairly decent menu-driven scheme. (I came to the second example
above by first doing showMethods("[") and then copying classes from one
line of the output--clearly the software could do this better than the
human).
Duncan Murdoch wrote:
> On 9/30/2006 1:17 AM, hadley wickham wrote:
>
>>> Yes, I agree that the current help system doesn't work very well on S3
>>> methods. But I don't know how to fix it. I think the only way it could
>>> know what to do on a construction like
>>>
>>> ?summary(lm(...))
>>>
>>> would be to actually evaluate summary(lm(...)) (or maybe just lm(...)),
>>> and I think that would be a huge mistake in the user interface. Some
>>> functions have side effects, and you don't want to evaluate them unless
>>> the user asks you to. Asking for help on something should give you
>>> help, it shouldn't do the thing.
>>>
>> I keep flipping back and forth on whether or not that's a problem. I
>> agree that it's not desirable, but may be an ok compromise in
>> principle. How does the S4 help search work?
>>
>
> See the .helpForCall function in utils. It would recognize that the
> function was an S4 generic, and then work out the signature and look for
> matching help. I think working out the signature in the case above
> would require it to call lm(...). So there's a precedent for what I
> called a "huge mistake": maybe it's not so huge...
>
> Duncan Murdoch
>
>
>
>
>
>>> Do you have an actual suggestion for a change to the current behaviour?
>>>
>> One obvious heuristic (which I used with the hints function I wrote a
>> while back) is to iterate through the classes of the first argument
>> looking for functions (with documentation) of the form generic.class1,
>> generic.class2 etc.
>>
>> Obviously this will fail for functions that don't dispatch on the
>> first method, but there probably aren't that many.
>>
>> Hadley
>>
>
> ______________________________________________
> 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
