[Rd] loadings() generic in R alpha

[Paul Gilbert]

Brian

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

Paul

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