Could loadings() in R-2.2.0 please be made generic? Thanks, Paul Gilbert
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?) -- Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595
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?)
>
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?)
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?) >>> >>>
>>>>> "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