From ripley at stats.ox.ac.uk  Mon Jan 19 18:17:39 2004
From: ripley at stats.ox.ac.uk (Prof Brian Ripley)
Date: Mon Jan 19 18:16:04 2004
Subject: [Rd] Wish list
In-Reply-To: <20040119112942.1997780d.feh3k@spamcop.net>
Message-ID: <Pine.LNX.4.44.0401191706500.4852-100000@gannet.stats>

Are you sure there is a measurable difference in calling methods directly?
The dispatch overhead on formula (one of your uses) appears to be about
10 microseconds.  (Note, negligible even for 10,000 bootstraps.)

I believe we took the real performance penalties into account (and 
namespaces had performance pluses as well as minuses).

On Mon, 19 Jan 2004, Frank E Harrell Jr wrote:

> On Mon, 19 Jan 2004 14:09:58 +0000 (GMT)
> Prof Brian Ripley <ripley@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@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.

What is the problem with coercing to the right class and calling the 
generic.

-- 
Brian D. Ripley,                  ripley@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


[Rd] Wish list
Prof Brian Ripley