From chalabi at phys.ethz.ch  Mon Mar  9 09:19:44 2009
From: chalabi at phys.ethz.ch (Yohan Chalabi)
Date: Mon, 9 Mar 2009 09:19:44 +0100
Subject: [Rd] S4 objects for S3 methods
In-Reply-To: <49B19FB0.9030606@r-project.org>
References: <49B19FB0.9030606@r-project.org>
Message-ID: <20090309091944.2d5c594d@mimi>

>>>> "JC" == John Chambers <jmc at r-project.org>
>>>> on Fri, 06 Mar 2009 14:12:00 -0800

   JC> Some modifications have been committed for the r-devel
   JC> version today
   JC> that modify (essentially, correct a bug in) the communication
   JC> of objects
   JC> to an S3 method from an S4 class that extends the S3 class.
   JC>
   JC> This is one of a sequence of changes designed to make S4
   JC> classes work
   JC> more generally and consistently with S3 methods and classes.
   JC>
   JC> In 2.8.0, support was provided for S4 classes that extend
   JC> S3 classes,
   JC> partly by making S3 method dispatch recognize the inheritance.
   JC>
   JC> The catch was that the S3 method would get the S4 object.
   JC> Two problems
   JC> with that:
   JC>
   JC> 1. The S3 method would fail if it tried to use the S3 class
   JC> information
   JC> directly, since the class attribute was the S4 class.
   JC>
   JC> 2. More seriously, if the method used the object, modified
   JC> it and
   JC> returned the result, it had a good chance of returning an
   JC> invalid object
   JC> seeming to come from the S4 class.
   JC>
   JC> The modification to deal with this now delivers to the S3
   JC> method the
   JC> inherited S3 object.  (This turned out to be somewhat harder
   JC> than the
   JC> original change, since it impacts several pieces of internal
   JC> code.)  A
   JC> revision of the function asS4() deals with similar concerns--see
   JC> the
   JC> documentation.
   JC>
   JC> The change does not affect default methods.  It would be
   JC> tempting to
   JC> convert S4 objects for those, but some S3 generics attempt to
   JC> deal with
   JC> S4 objects, e.g., str().  A change to the primitives that
   JC> dispatch
   JC> methods is more plausible, but for the moment all that was
   JC> added was
   JC> more explicit error messages if a non-vector S4 object is
   JC> supplied.
   JC>
   JC> For more information see the section on inheriting from
   JC> non-S4 classes
   JC> in the documentation ?Classes.
   JC>
   JC> It would be helpful if package maintainers would check this
   JC> and previous
   JC> changes by running their code against the r-devel version of
   JC> R, before
   JC> that becomes 2.9.0.  Please report any new errors (provided,
   JC> of course,
   JC> that the same code works with 2.8.1).
   JC>
   JC> John
   JC>
  

Dear John,

it seems that S3 methods for an S4 class which extents a
matrix cannot be defined as it used to be the case in 2.8.1.

For example

## code
setClass("aTest",
         representation(.Data = "matrix",
                        comment = "character"))


c1 <- new("aTest", .Data = matrix(1:4, ncol = 2), comment = "aTest")

# it seems that it is no longer possible to define an S3
# method for the class aTest

print.aTest <- function(x, ...)
{
    cat("\n", x at comment, "\n")
    print(getDataPart(x))
}

print.aTest(c1)
print(c1) # works in 2.8.1

# another example could be
as.matrix.aTest <- function(x, ...) getDataPart(x)

as.matrix.aTest(c1)
as.matrix(c1) # works in 2.8.1

## end code


Is this the expected behavior?


Best regards,
Yohan

-- 
PhD student
Swiss Federal Institute of Technology
Zurich

www.ethz.ch



[Rd] S4 objects for S3 methods
Yohan Chalabi