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

[Gabor Grothendieck]

The generics don't have to be S4.  In fact, in many cases it would
be better to have them be S3 for consistency with other similar generics
in the core of R.

Or I wonder about the possibility of having generics which can have
some methods being of S3 and others of S4.

On 5/9/07, Robert Gentleman <rgentlem at fhcrc.org> wrote:
>
>
> 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
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>