[Rd] loadings() generic in R alpha

[Paul Gilbert]

Gavin Simpson wrote:

>On Fri, 2005-09-16 at 12:52 -0400, Paul Gilbert wrote:
>  
>
>>Brian
>>
>>It would help if I understood general principles. I thought one would 
>>want a case for NOT making functions generic, rather than a case for 
>>making them generic. Hopefully a case for why generics and methods are 
>>useful will not be necessary.
>>
>>The situation with loadings() is that I construct objects where the 
>>loadings are in a list within a list, so the simple definition in stats 
>>does not work:
>>
>>loadings
>>function (x)
>>x$loadings
>><environment: namespace:stats>
>>
>>Basically this definition restricts the way in which objects can be 
>>constructed, so I would like it replaced by
>>
>>loadings <- function (x) UseMethod("loadings")
>>loadings.default <- function (x) x$loadings
>>    
>>
>
>Paul,
>
>The writing R extensions manual suggests the following way of hi-jacking
>a function and making it generic:
>
>loadings.default <- stats::loadings
>
>As long as your function had argument x this should work, no?
>
>Are there problems with this approach? - I'm interested as I've used
>that method in a package I am currently finishing up, which seems to
>work fine in my particular case.
>
Gavin

Hi-jacking works, at least as long as only one package does it. I've 
been doing that for several years now. I'm not sure what happens when 
two packages try to hi-jack the same function, and especially if they 
define the generic differently. I think with namespaces there is 
protection within your own package code, but not protection for anything 
a user might define. I am especially worried about loadings(), as that 
seems like something lots of packages may want to hi-jack.

There are also some additional considerations when namespaces are used. 
For example, to hi-jack loadings one would typically want to put 
something like this in the package code:

if (!exists("loadings.default", mode="function")){
  loadings.default  <- stats::loadings
  loadings <- function(x)UseMethod("loadings")
  }

The if statement is so that the package continues to work if it is 
decided to make loadings generic in  a new version of stats. But exists 
does not work since stats has namespaces (at least not in R-2.1.1, but 
it may be fixed in R-2.2.0). If it is broken then there is no easy way I 
know about to protect against everything in my package getting broken by 
a new release of R.  (Now you may think this last is wishful thinking, 
but so far I have been fairly lucky.)

Paul

>
>One reason that same manual states for preferring not to make everything
>generic is that it incurs a small performance cost
>
>I'd be interested in hearing other people's views on this approach -
>it's still not too late to change things in my package if I am blindly
>teetering on the brink of impending disaster...
>
>G
>
>  
>
>>There may be a reason for adding a ... argument, but I have been using 
>>this generic and methods for it in my own work for a fairly long time 
>>now and have not discovered one.  The change seems rather trivial, I 
>>have tested it extensively with my own code, and there is a fairly 
>>complete test suite in place for checking changes to R,  so it seems 
>>reasonable to me that this should be considered as a change that is 
>>possible in an alpha release. It would also be fairly easy to back out 
>>of if there are problems.
>>
>>The reason for needing  acf generic is the same, so that it can be use 
>>with more complicated objects that I construct. However, I see here that 
>>there are potentially more difficult problems, because the ... argument 
>>to the current acf (which one would want as the default method) is 
>>passed to plot.acf.  Here I can clearly see the reason for wanting to 
>>start consideration of this at an earlier point in the development cycle.
>>
>>Best,
>>Paul
>>
>>Prof Brian Ripley wrote:
>>
>>    
>>
>>>On Thu, 15 Sep 2005, Paul Gilbert wrote (in two separate messages)
>>>
>>>      
>>>
>>>>Could loadings()  in R-2.2.0  please be made generic?
>>>>        
>>>>
>>>      
>>>
>>>>Could acf()  in R-2.2.0  please be made generic?
>>>>        
>>>>
>>>I think it is too late in the process for this (and especially for 
>>>acf). In particular, it could have knock-on consequences for packages 
>>>and recommended packages are scheduled to be all fixed in stone by 
>>>next Weds.
>>>
>>>To consider making such functions generic we would need
>>>
>>>- a case
>>>- discussion of what the arguments of the generic should be and what is
>>>  to be specified about the return value.
>>>
>>>Perhaps you could raise these again with specific proposals early in 
>>>the developement cycle for 2.3.0.
>>>
>>>(We have been a little too casual about speciying what generic 
>>>functions should return in the past, and have got bitten as a result.  
>>>For example, can it be assumed that loadings() returns a matrix?)
>>>
>>>      
>>>
>>______________________________________________
>>R-devel at r-project.org mailing list
>>https://stat.ethz.ch/mailman/listinfo/r-devel
>>    
>>