From ripley at stats.ox.ac.uk  Wed May  9 16:08:55 2007
From: ripley at stats.ox.ac.uk (Prof Brian Ripley)
Date: Wed, 9 May 2007 15:08:55 +0100 (BST)
Subject: [Rd] One for the wish list - var.default etc
In-Reply-To: <s641d024.022@tedmail2.lgc.co.uk>
References: <s641d024.022@tedmail2.lgc.co.uk>
Message-ID: <Pine.LNX.4.64.0705091353090.30339@auk.stats>

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.

> The other option, with no existing generic, is to mask the original 
> function by writing a new generic function that respects the original 
> syntax exactly, and then implement a fun.default that replicates the 
> original non-generic function's behaviour, hopefully by calling it 
> directly. As an example, library(circular) masks stats::var, though I'm 
> fairly sure its not the only case. This has obvious disadvantages, 
> including potentially system-wide (R-wide at least!) impact and 
> unfavourable interactions between packages masking each other's generics 
> and defaults).

Just as can happen with methods.

> I will use masking if I have to, at least for my own local use where its 
> only me that suffers if (when?) I get it wrong. But the idea makes me 
> very nervous, especially if I imagine folk who _don't_ get as nervous at 
> the idea.
>
> Hence the feeling that wider use of generics for fundamental and common 
> functions might make for a safer world.

The opposite appears to be truer.

-- 
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



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