On Fri, 2005-09-16 at 12:52 -0400, 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.
>
> 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
Paul,
The writing R extensions manual suggests the following way of hi-jacking
a function and making it generic:
loadings.default <- stats::loadings
As long as your function had argument x this should work, no?
Are there problems with this approach? - I'm interested as I've used
that method in a package I am currently finishing up, which seems to
work fine in my particular case.
One reason that same manual states for preferring not to make everything
generic is that it incurs a small performance cost
I'd be interested in hearing other people's views on this approach -
it's still not too late to change things in my package if I am blindly
teetering on the brink of impending disaster...
G
>
> 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?)
> >
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
Gavin Simpson [T] +44 (0)20 7679 5522
ENSIS Research Fellow [F] +44 (0)20 7679 7565
ENSIS Ltd. & ECRC [E] gavin.simpsonATNOSPAMucl.ac.uk
UCL Department of Geography [W] http://www.ucl.ac.uk/~ucfagls/cv/
26 Bedford Way [W] http://www.ucl.ac.uk/~ucfagls/
London. WC1H 0AP.
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
