Hi. Some clarification on R.oo:
-----Original Message-----
From: r-devel-bounces@stat.math.ethz.ch
[mailto:r-devel-bounces@stat.math.ethz.ch] On Behalf Of A.J. Rossini
Sent: Wednesday, April 20, 2005 6:21 PM
To: Ali -
Cc: r-devel@stat.math.ethz.ch
Subject: Re: [Rd] Overloading methods in R
R.oo tries to implement an old-fashioned OO system as found
in Java, Python, C++, etc. R's S4 methods implement a nice
modern system based on the generic function approach ,
dispatch on argument signatures, which is different.
I would call them different, rather than old and modern - each kind has its
own use.
To the details:
It is the Object class that is related to Java & co; the setMethodS3() and
setConstructorS3() methods are orthogonal and just userfriendly wrappers to
creating functions manually.
The main purpose of Object is provide *reference variables*, with the main
purpose to save memory! This is done by utilizing environment, which is
standard R code, no ugly hacks are used. The Object class defines operators
"$" and "$<-" (and a few others) to access variables within the
environment,
which is unique to each instance of class Object. Indeed, there was a
similar feature added in R v1.9.0 (or was it v2.0.0) to the environment
variable; "$" and "$<-" wraps up get() and assign() methods for easy use.
For an object Object, the environment is in a list structure, contrary to
being an environment directly. The reason for this is that attr(), save()
and load() on environments does (did?) not work as you would expect, cf.
https://stat.ethz.ch/pipermail/r-devel/2002-October/025197.html.
The the Object class defines some other methods to simplify life, and yes,
to imitate Java in the sense that it is convenient to inherit from one
single root Class. It does not allow multiple inheritance (although you can
update the class attributes yourself if you wish too).
To differ between OOP in Java and S4/Dylan, I prefer to refer to the former
as
class-object-oriented programming (COOP) and the latter as
function-object-oriented programming (FOOP). Then, comparing COOP style
with
FOOP style is a bit like comparing peas to apples. I would say that
choosing
COOP or FOOP is a design issue that has to do what you are trying to
implement and not a
once-in-a-lifetime/I-want-to-belong-to-this-group-of-people decision. For
what I am working on, I found that higher level implementation, where it is
clear that a method "belongs" to a class, is easier using COOP. Classes for
statistical and mathematical modelling, where functions does not belong to
a
specific object, is probably better i FOOP. So, please do not rule out one
for the other!
The setMethodS3() is a wrapper to automatically test for generic and
default
functions and create generic functions when needed etc. So
setMethodS3("foo", "MyClass", function(object, ...) {
#something
})
replaces things like
if (exists("foo.MyClass", mode="function"))
warning/stop("Replacing foo.MyClass")
if (exists("foo", mode="function") && !"not a generic function")
try to rename foo() to foo.default(), but only if foo.default()
does not already exists.
... and so on until you can safely write
foo.MyClass <- function(object, ...) {
# something
}
setConstructorS3() is basically like the above, but it does not create a
generic function nor a class specific method, but a "plain" function
setConstructorS3("MyClass", function(args, ...) {
# Something
}
to get
MyClass <- function(args, ...) {
# Something
}
with check for naming conflicts etc.
Cheers
Henrik Bengtsson
(author of R.oo)
While the R documentation for S4 classes is quite useful
(spanning the green book, the BioC developer help pages,
V&R's book on programming, and some other papers), I've found
that for a nice background, Paul Graham's ANSI Lisp book, and
in particular the nicely written chapter on CLOS, provides a
nice introduction to the thought process.
With respect to the R.oo package, the author might be the
best source for that.
Another package which you might take a look at is the proto
package, which provides prototype object-orientation similar
to that found in XLispStat, and also might help with what you
are trying to do.
However, I suspect that learning about the S4 system will
provide more benefit in the future.
best,
-tony
On 4/20/05, Ali - <saveez@hotmail.com> wrote:
Sean,
Thanks, but, I am actually talking about overloading
'functions', or you may want to answer this question: How
methods in classes created by R.oo package?
On Apr 20, 2005, at 8:16 AM, Ali - wrote:
(1) It seems to me that, generally, in R it is not possible to
overload functions. Is that right?
(2) Assuming that the above is true, or partially true,
extra packages to handle overloading in R?
(3) Assuming (1) is TRUE and (2) is FALSE, can anyone
advice on developing some function that understand what the
arguments are and then calls the right overloaded function?
It would be something like this:
overloadedFunction1 <- function(x) {};
overloadedFunction2 <- function(x, y) {};
theFunction <- function(...)
{
# How to identify ... and call the right overloaded function? }
Ali,
You are probably interested in "methods". Functions can
"methods" depending on what the arguments and their types