[Rd] Generics in base with no ...

[Herve Pages]

Duncan Murdoch wrote:
> On 12/07/2007 6:17 PM, Herve Pages wrote:
>> Hi,
>>
>> Some generics in base that don't have the ... extra argument:
>> rev(), t(), scale() and unlist(). Is there any plan to make these
>> more reusable? I used to be interested in having a rev() method for
>> my objects, but since I needed an extra argument for it, then I was
>> forced to create my own generic instead. And because I didn't want
>> to mask base::rev(), I chose another name too. The only advantage
>> of doing this is that the man page for myrev() was more accessible
>> than if I had made a rev() method. But it would be nice to make the
>> rev() generic more reusable anyway, just because the name "rev"
>> itself is good and easy to remember.
> 
> It would be helpful to give specific examples of use cases.  As far as I
> know, adding the ... makes every call slower; this is acceptable if
> there's a good reason to do it, but I think we should think about it.
> 
> rev() in particular seems as though it should always take an ordered
> thing and return the same kind of thing but in the reversed order:  why
> would you want to add optional args, and still call it rev?  If you're
> using some user-specified ordering, wouldn't it be better to use sort(),
> instead?

My objects have a name which is stored in a slot. When I revert it, I need
to rename it too because I don't want to end up with 2 different objects
having the same name. I could do y <- rev(x); y at objName <- "new name" but
this is not conceptually very good: the action of reversing _and_ renaming
should be atomic. So I wanted to add an 'objName' arg to my rev() method.

You could also imagine that the individual elements of the ordered thing
you want to revert are themselves ordered things. So maybe you just want
to reverse the top level elements or you want this to be recursive ("deep"
reversing). Then you need an extra argument like the 'recursive' arg of
the unlist() generic to control this.

Anyway, I was not aware of the performance penalty introduced by adding ...
so I understand now why these generics have not been modified so far.

Thanks!
H.


> 
> Duncan Murdoch
>