[Rd] loadings() generic in R alpha

[Martin Maechler]

>>>>> "PaulG" == Paul Gilbert <pgilbert at bank-banque-canada.ca>
>>>>>     on Fri, 16 Sep 2005 14:04:37 -0400 writes:

    PaulG> Brian Ok, lets leave this for now. When does the
    PaulG> development cycle start for the next version that
    PaulG> would allow making a function generic?

Almost immediately after 2.2.0 is released.

    PaulG> Paul

    PaulG> Prof Brian D Ripley wrote:

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

    PaulG> ______________________________________________
    PaulG> R-devel at r-project.org mailing list
    PaulG> https://stat.ethz.ch/mailman/listinfo/r-devel