[Rd] loadings() generic in R alpha

[Gavin Simpson]

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.

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
-- 
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
Gavin Simpson                     [T] +44 (0)20 7679 5522
ENSIS Research Fellow             [F] +44 (0)20 7679 7565
ENSIS Ltd. & ECRC                 [E] gavin.simpsonATNOSPAMucl.ac.uk
UCL Department of Geography       [W] http://www.ucl.ac.uk/~ucfagls/cv/
26 Bedford Way                    [W] http://www.ucl.ac.uk/~ucfagls/
London.  WC1H 0AP.
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%