[Rd] Problem in 'methods' package (PR#4525)

John Chambers jmc at research.bell-labs.com
Sun Oct 12 20:37:16 MEST 2003


David James wrote:
> 
> Hello,
> 
> It seems to me that Fernando may be right.  The problem seems to be
> in R 1.8.0 when defining generics with explicit valueClass.  E.g.,
> 
> R-1.7.1:
> 
>    > setGeneric("foo", function(x) standardGeneric("foo"), valueClass="numeric")
>    > setMethod("foo", "numeric", function(x) x )
>    > foo(pi)
>    [1] 3.141593
> 
> R-devel (1.9.0):  (I don't have 1.8.0 handy at this moment).
> 
>    > setGeneric("foo", function(x) standardGeneric("foo"), valueClass="numeric")
>    > setMethod("foo", "numeric", function(x) x )
>    > foo(pi)
>    Error in foo(pi) : couldn't find function ".valueClassTest"
> 
> whether the problem is in the methods package or the namespace code,
> I cannot say.
> 
> --
> David

The simple patch is to add

export(.valueClassTest)

to the NAMESPACE file in the methods package.  This has been done &
committed to r-patched.

However, the longterm best approach is not so obvious.  The valueClass
argument to setGeneric is an addition to the API in the green book.  If
we want to keep it, a different implementation will be needed.

The current mechanism revises the body of the generic function to
include the call to .valueClassTest, but leaves the class of the generic
as "standardGeneric", which is in principle wrong.  A standardGeneric
function is defined to ONLY dispatch methods.  In the present version of
R, that doesn't matter because the body of the function is evaluated as
for any function, but in the future we want to take advantage of
"standardGeneric"-ness by special evaluation.

At that point, the valueClass= argument would need to create a
nonstandardGenericFunction object.  OK, but that raises the question of
whether this special mechanism is worth having.  The class validity test
is just a special case of the general idea of nonstandard generic
functions.  In the example, the call to setGeneric could be of the form
setGeneric("foo", def = fooDef), where fooDef is something like

function(x) {
  value <- standardGeneric("foo")
  if(!is(value,"numeric"))
    stop("foo must return a numeric object for any argument")
  value
}
This is a special case of generics that impose some validity requirement
on the value returned by the method.

Should we complicate the definition of generic functions just to deal
with the particular case of checking for a list of classes?  Seems
questionable, given that it's not imposed by the API.

John

> 
> Uwe Ligges wrote:
> > feferraz at linux.ime.usp.br wrote:
> > >
> > > Full_Name: Fernando Henrique Ferraz Pereira da Rosa
> > > Version: 1.8.0
> > > OS: Linux 2.4.21
> > > Submission from: (NULL) (200.206.211.169)
> > >
> > >      After installing R 1.8.0, the R DBI interface stopped working. I tracked it
> > > down as a problem in the 'methods' package, that comes in the default
> > > installation.
> > >      Somehow the function '.valueClassTest' which is defined on package
> > > 'methods', is not being defined.
> >
> > It is. See below.
> >
> > >      To ilustrate how this breaks DBI, try this in a 1.8.0 R install (with DBI
> > > installed):
> > >
> > >       > library(DBI)
> > >       > con <- dbConnect(dbDriver("MySQL"), dbname = "test")
> > > Error in dbConnect(dbDriver("MySQL"), dbname = "test") :
> > >         couldn't find function ".valueClassTest"
> > >
> > >       A dirty fix would be defining it by hand (from
> > > src/library/methods/R/RMethodUtils.R) :
> > >
> > >    .valueClassTest <- function(object, classes, fname) {
> > >         (...)
> > >     }
> > >
> > >        (Which works), but ideally it'd be nice determning why the function is
> > > not being defined on the first place.
> >
> > Package "methods" has a namespace from which .valueClassTest() is not
> > exported, but it's in there, try:
> >   methods:::.valueClassTest
> >
> > I think .valueClassTest() is not intended to be called by the user, so
> > the bug seems to be in package DBI rather than in R, and the maintainer
> > of DBI (David A. James <dj at bell-labs.com>, in CC) will certainly fix it.
> >
> > Uwe Ligges
> 
> --
> David A. James
> Statistics Research, Room 2C-253            Phone:  (908) 582-3082
> Bell Labs, Lucent Technologies              Fax:    (908) 582-3340
> Murray Hill, NJ 09794-0636



More information about the R-devel mailing list