[Rd] One for the wish list - var.default etc

[Jeffrey J. Hallman]

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. 

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. 

-- 
Jeff