From ggrothendieck at gmail.com  Wed May  9 15:28:42 2007
From: ggrothendieck at gmail.com (Gabor Grothendieck)
Date: Wed, 9 May 2007 09:28:42 -0400
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: <971536df0705090628k3f50b63bn5bc1138aab1c5ee@mail.gmail.com>

I agree that wider use of generics in the core of R is desirable as
it facilitates designs in various addon packages that are much easier
to use.  In the absence of generics, the addon package either has to
clobber/mask the version in the core, which really is unacceptable, or define
a different name which adds the mental load of having to remember
yet something else whenever you use that aspect of the package.

filter, as.POSIXlt, rowMeans, rowSums, integrate and various lattice
panel functions are others that I would like to see made
generic for the sake of zoo, fame and/or Ryacas and likely other
packages.

On 5/9/07, S Ellison <S.Ellison at lgc.co.uk> 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.
>
> 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).
>
> 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.
>
>
> Steve E
>
> *******************************************************************
> This email and any attachments are confidential. Any use, co...{{dropped}}
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



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