One for the wish list - var.default etc

Jeffrey J. Hallman wrote:

Prof Brian Ripley <ripley at stats.ox.ac.uk> writes:

On Wed, 9 May 2007, S Ellison wrote:

Brian,

If we make functions generic, we rely on package writers implementing
the documented semantics (and that is not easy to check).  That was
deemed to be too easy to get wrong for var().

Hard to argue with a considered decision, but the alternative facing
increasing numbers of package developers seems to me to be pretty bad
too ...

There are two ways a package developer can currently get a function
tailored to their own new class. One is to rely on a generic function to
launch their class-specific instance, and write only the class-specific
instance. That may indeed be hard to check, though I would be inclined
to think that is the package developer's problem, not the core team's.
But it has (as far as I know today ...?) no wider impact.

But it does: it gives the method privileged access, in this case to the
stats namespace, even allowing a user to change the default method
which namespaces to a very large extent protect against.

If var is not generic, we can be sure that all uses within the stats
namespace and any namespace that imports it are of stats::var.  That is
not something to give up lightly.

No, but neither is the flexibility afforded by generics. What we have here is
a false tradeoff between flexibility vs. the safety of locking stuff down.

  Yes, that is precisely one of the points, and as some of us recently
experienced, a reasonably dedicated programmer can over-ride any base
function through an add-on package. It is, in my opinion a bad idea to
become the police here.

  AFAIK, Brian's considered decision, was his, I am aware of no
discussion of that particular point of view about var (and as noted
above, it simply doesn't work), it also, AFAICS confuses what happens
(implementation) from what should happen (which is easy to do, because
with most of the methods, either S3 or S4 there is very little written
about what should happen).

  That said, there has been some relatively open discussion on one
solution to this problem, and I am hopeful that we will have something
in place before the end of July.

  A big problem with S4 generics is who owns them, and what seems to be
a reasonable medium term solution is to provide a package that lives
slightly above base in the search path that will hold generic functions
for any base functions that do not have them. Authors of add on packages
can then at least share a common generic when that is appropriate. But
do realize that there are lots of reasons to have generics with the same
name, in different packages that are not compatible, and normal scoping
rules apply. For example the XML package has a generic function addNode,
as does the graph package, and they are not compatible, nor should they
be. Anyone wanting to use both packages (and I often do) needs to manage
the name conflicts (and that is where namespaces are essential).

best wishes
  Robert

The tradeoff is false because unit tests are a better way to assure safety.
If the major packages (like stats) had a suite of tests, a package developer
could load his own package, run all the unit tests, and see if he broke
something.  If it turns out that he broke something that wasn't covered by the
tests, he could create a new test for that and submit it somewhere, perhaps
on the R Wiki.

--
Robert Gentleman, PhD
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
PO Box 19024
Seattle, Washington 98109-1024
206-667-7700
rgentlem at fhcrc.org