[Rd] loadings() generic in R alpha

[Paul Gilbert]

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

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?)
>