On 08/04/2013 02:13 AM, Simon Zehnder wrote:
So, I found a solution: First in the "initialize" method of class C coerce
the C object into a B object. Then call the next method in the list with the
B class object. Now, in the "initialize" method of class B the object is a B
object and the respective "generateSpec" method is called. Then, in the
"initialize" method of C the returned object from "callNextMethod" has to be
written to the C class object in .Object. See the code below.
setMethod("initialize", "C", function(.Object, value) {.Object@c <- value;
object <- as(.Object, "B"); object <- callNextMethod(object, value);
as(.Object, "B") <- object; .Object <- generateSpec(.Object);
return(.Object)})
This setting works. I do not know though, if this setting is the "usual" way
such things are done in R OOP. Maybe the whole class design is
disadvantageous. If anyone detects a mistaken design, I am very thankful to
learn.
Hi Simon -- your 'simple' example is pretty complicated, and I didn't really
follow it in detail! The code is not formatted for easy reading (e.g., lines
spanning no more than 80 columns) and some of it (e.g., generateSpec) might not
be necessary to describe the problem you're having.
A good strategy is to ensure that 'new' called with no arguments works (there
are other solutions, but following this rule has helped me to keep my classes
and methods simple). This is not the case for
new("A")
new("C")
The reason for this strategy has to do with the way inheritance is implemented,
in particular the coercion from derived to super class. Usually it is better to
provide default values for arguments to initialize, and to specify arguments
after a '...'. This means that your initialize methods will respects the
contract set out in ?initialize, in particular the handling of unnamed arguments:
...: data to include in the new object. Named arguments
correspond to slots in the class definition. Unnamed
arguments must be objects from classes that this class
extends.
I might have written initialize,A-method as
setMethod("initialize", "A", function(.Object, ..., value=numeric()){
.Object <- callNextMethod(.Object, ..., a=value)
generateSpec(.Object)
})
Likely in a subsequent iteration I would have ended up with (using the
convention that function names preceded by '.' are not exported)
.A <- setClass("A", representation(a = "numeric", specA = "numeric"))
.generateSpecA <- function(a) {
1 / a
}
A <- function(a=numeric(), ...) {
specA <- .generateSpecA(a)
.A(..., a=a, specA=specA)
}
setMethod(generateSpec, "A", function(object) {
.generateSpecA(object@a)
})
ensuring that A() returns a valid object and avoiding the definition of an
initialize method entirely.
Martin
Best
Simon
On Aug 3, 2013, at 9:43 PM, Simon Zehnder <simon.zehn...@googlemail.com>
wrote:
setMethod("initialize", "C", function(.Object, value) {.Object@c <- value;
.Object <- callNextMethod(.Object, value); .Object <-
generateSpec(.Object); return(.Object)})
______________________________________________ R-help@r-project.org mailing
list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting
guide http://www.R-project.org/posting-guide.html and provide commented,
minimal, self-contained, reproducible code.
--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
