[Rd] loadings() generic in R alpha

[Prof Brian D Ripley]

On Fri, 16 Sep 2005, 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.

Making things generic

1) adds runtime cost

2) essentially fixes the signature for all time

3) needs the return value sufficiently well defined that all current uses
will not be broken by a new method.  (This was not a problem with e.g.
as.ts as everone knows the result should be a "ts" object.  But I think it
is a problem with acf and loadings.)

I would for example be unhappy with your definition of loadings() as it has
no ... argument (and S-PLUS has one in its loadings() generic).

So cases are necessary.  I am pretty sure that we have in the past agreed
that making a function generic is a Grand Feature, and we are in GFF.


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