>>>>> "PaulG" == Paul Gilbert <[EMAIL PROTECTED]> >>>>> 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@r-project.org mailing list PaulG> https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel