[Rd] Overloading methods in R

Thu Apr 21 13:28:13 CEST 2005

Henrik,

Thanks for a reply as the author of the package. I understand that you 
people are interested in discussing this COOP-FOOP fight, however, the 
original question of this thread is all forgotton. So, I declare the 
question again:

-> How to overload methods in classes created by R.oo package? <-

I even sent you this question by the email provided in the package, but 
still no answer!

I am trying to wrap some C++ class into R, so, in the way that you 
described, I am trying to wrap some COOP 'things' by some FOOP 'things'. 
Although there are some packages in R that already wrapped some C++ classes 
into R, none of them kept the originality of the wrapped classes. That is, 
the original C++ classes are customised and dissolved to R functions. There 
is nothing wrong with doing this, but, I am wrapping a few hundered C++ 
classes automatically and apparently it is not possible to customise each of 
them.

The good thing about R.oo is that it is a trouble-less interface between 
COOP and FOOP. In fact, I have already used the package successfully to 
generate S3 classes from C++ *automatically*. The only big issue that I have 
with it is that R.oo overwrites overloaded methods and, to keep the 
originality of the C++ class and bein nice to the end user, I don't want to 
change the name of the overloaded functions. Also there is this point that 
sometime in feature S3 classes will become completely obsolete and new 
packages shouldn't be based on it. So it would be nice to have a 'S4-R.oo'.

Finally, I remind the package author about the original question:

- How to overload methods in classes created by R.oo package?

with one more question that I add it right now:

- Why R.00 is not upgraded to S4?

and I hope we have some 'answer'.

-Ali

>Hi. Some clarification on R.oo:
>
> > -----Original Message-----
> > From: r-devel-bounces at stat.math.ethz.ch
> > [mailto:r-devel-bounces at stat.math.ethz.ch] On Behalf Of A.J. Rossini
> > Sent: Wednesday, April 20, 2005 6:21 PM
> > To: Ali -
> > Cc: r-devel at 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 at hotmail.com> wrote:
> > > Sean,
> > >
> > > Thanks, but, I am actually talking about overloading
> > 'methods' and not
> > > 'functions', or you may want to answer this question: How
> > to overload
> > > 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,
> > is there any
> > > >>extra packages to handle overloading in R?
> > > >>
> > > >>(3) Assuming (1) is TRUE and (2) is FALSE, can anyone
> > provide some
> > > >>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
> > have different
> > > >"methods" depending on what the arguments and their types
> > are.  A first
> > > >place to look is:
> > > >
> > >
> > >http://cran.r-project.org/doc/manuals/R-exts.html#Generic-functions-
> > > >and-methods
> > > >
> > > >Sean
> > > >
> > >
> > > ______________________________________________
> > > R-devel at stat.math.ethz.ch mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
> > >
> >
> >
> > --
> > best,
> > -tony
> >
> > "Commit early,commit often, and commit in a repository from
> > which we can easily
> > roll-back your mistakes" (AJR, 4Jan05).
> >
> > A.J. Rossini
> > blindglobe at gmail.com
> >
> > ______________________________________________
> > R-devel at stat.math.ethz.ch mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> >
>