I'm writing a package, and would appreciate advice on controlling the
help documentation cross-references for a redefined generic.
I wanted to define a cbind equivalent for an object that mostly behaves
like a data frame. base::cbind dispatches to a data frame method if
_any_ parameter is a data frame, so I defined a new S3 cbind and
cbind.default to handle dispatch on first object only. Though I confess
that redefining cbind leaves me a tad nervous, that all works OK so far.
However, R cmd tells me (rightly) that I haven't documented the generic
and new default. But I don't want to; I want ?cbind to point to the base
package help pages, not to mine.
Assuming that's not unwise (?), what do I have to do to tell R cmd that
it should not look for Rd docs for cbind and cbind.default in my package
whilst still having my generic handle dispatch correctly?
It looks like one answer _might_ be not to export my redefined cbind -
but will a local generic still work properly if it's not exported?
Steve Ellison
*******************************************************************
This email and any attachments are confidential. Any use...{{dropped:8}}
On 17/12/2009 11:08 PM, S Ellison wrote:> I'm writing a package, and would appreciate advice on controlling the > help documentation cross-references for a redefined generic. > > I wanted to define a cbind equivalent for an object that mostly behaves > like a data frame. base::cbind dispatches to a data frame method if > _any_ parameter is a data frame, so I defined a new S3 cbind and > cbind.default to handle dispatch on first object only. Though I confess > that redefining cbind leaves me a tad nervous, that all works OK so far. > > However, R cmd tells me (rightly) that I haven't documented the generic > and new default. But I don't want to; I want ?cbind to point to the base > package help pages, not to mine.But then the documentation will be incorrect, since it mentions the non-standard handling of dataframes, which you've done away with.> Assuming that's not unwise (?), what do I have to do to tell R cmd that > it should not look for Rd docs for cbind and cbind.default in my package > whilst still having my generic handle dispatch correctly? > > It looks like one answer _might_ be not to export my redefined cbind - > but will a local generic still work properly if it's not exported?I would say that what you've done is unwise. I would rename the function to avoid future confusion, especially if you decide to export it. Even if it's for internal use only, won't you want a reminder in 2 years time that cbind(a,b) doesn't mean what the documentation says it means? Duncan Murdoch
S Ellison <S.Ellison <at> lgc.co.uk> writes:> I wanted to define a cbind equivalent for an object that mostly behaves > like a data frame. base::cbind dispatches to a data frame method if > _any_ parameter is a data frame, so I defined a new S3 cbind and > cbind.default to handle dispatch on first object only. Though I confess > that redefining cbind leaves me a tad nervous, that all works OK so far.---- clipped ---> Steve EllisonWhy don't you just define a method for your object class. It should dispatch on your method if all of the objects that you give it have that class. I did this in the MLDS package in a situation in which I had a data frame that had additional attributes and I wanted rbind (in my case) to concatenate the attributes as well as the actual data frame. I gave the data frame with these extra attributes the class of c("mld.df", "data.frame") so that they would still inherit other data frame methods. My rbind.mlds.df works fine with them, and I document it accordingly. HTH. Ken -- Ken Knoblauch Inserm U846 Stem-cell and Brain Research Institute Department of Integrative Neurosciences 18 avenue du Doyen L?pine 69500 Bron France tel: +33 (0)4 72 91 34 77 fax: +33 (0)4 72 91 34 61 portable: +33 (0)6 84 10 64 10 http://www.sbri.fr/members/kenneth-knoblauch.html