[Rd] Wish list
Frank E Harrell Jr
feh3k at spamcop.net
Mon Jan 19 17:29:42 MET 2004
On Mon, 19 Jan 2004 14:09:58 +0000 (GMT)
Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:
> On Mon, 19 Jan 2004, Frank E Harrell Jr wrote:
>
> > On Sun, 18 Jan 2004 18:47:52 -0500
> > Duncan Murdoch <dmurdoch at pair.com> wrote:
> >
> > > On Sat, 17 Jan 2004 09:33:10 -0500, you wrote:
> > >
> > > >I also share your views about namespaces. These have caused
> > > >numerous problems for me. It would be nice to have more of a
> > > >mechanism to put"feelers" out to the R user community when major
> > > >changes are planned.
> > >
> > > Changes always show up in r-devel (the main CVS branch, not the
> > > mailing list) first. Package developers should be keeping a
> > > relatively up to date copy of it around if they're doing things that
> > > are likely to break.
> >
> > I need to do that more often. But sometimes it's hard to know what
> > things I do that are likely to break. That's where there needs to be
> > some other mechanism for user communications.
>
> Well, there is a NEWS file that is worth consulting, and we (Kurt in
> particular) run all the CRAN packages after every major change and
> daily. See http://cran.r-project.org/src/contrib/checkSummary.html. We
> do also tend to tell package authors directly if their packages break,
> at least if they were previously warning-free.
I will start checking NEWS. The kind of news I need though is more about
bugs that do not cause the package to break.
>
> It seems the sort of thing you do is to call methods directly where you
> could equally well call the generic, since that is what is currently
> failing in Design and Hmisc (if survfit.km is a survfit method).
The point of calling methods directly is efficiency, otherwise I would not
use this dirty practice. When bootstrapping or otherwise calling methods
repeatedly, I seek the lowest level functions for speed. This conflicts
with the namespace idea. I think this should have been taken into
consideration when designing namespaces.
>
> > > >In Hmisc and Design I reference several functions that were not
> > > >exported from packages that now use namespaces. There is an
> > > >elegant
>
> That's not showing up in failures on the tests under R-patched. Of the
> listed dependencies only grid, lattice and survival have namespaces, and
> only survival has been added since 1.8.1. (I suspect the R-patched
> tests are against the 1.8.1 versions of the recommended packages, not
> the current versions.)
Yes, those are the ones.
>
> > > >solution with the package:::function notation,
> > >
> > > I'd recommend avoiding that as much as you can. If things aren't
> > > exported from a package, then the package writer is likely to feel
> > > free to change them without warning. It's much better to convince
> > > the package writer that they missed something in their export list.
Right
> >
> > That's a good solution in general, but I could see legitimate
> > disagreements about what should be exported, so this will not always
> > solve the problem.
>
> I think it does. If the package writer wants a function to be private,
> would-be users should respect that decision. Most of the cases we have
> encountered have been calling methods directly rather than coercing
> objects to the right class and calling the generic. In extremis, copy
> (with permission) the function you want from the package sources and
> rename it.
That is a possibility. None of the approaches we've named are without
maintenance problems.
Frank
>
> Unless I made a mistake there are no current uses of ::: in CRAN
> packages, and there are very few in base R (and quite a lot of the
> methods::: should probably better be methods::).
>
> Brian
>
> --
> 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
>
---
Frank E Harrell Jr Professor and Chair School of Medicine
Department of Biostatistics Vanderbilt University
More information about the R-devel
mailing list