Hi,
A few comments from a fairly experienced R user who
worked for several years on a R-based bioinformatics
analysis framework.
I don't want to misrepresent anyone's views, but...
There are real disadvantages to the
"objects-as-C-structs" and functions/methods which
"mutate" based on argument type. i.e. S4.
(1)Novices simply don't understand it. Students are
trained in "standard" object-oriented technique and
this wonkish offshoot(puritanical functional
programming) just increases the information costs to
using R and thus decreases the demand.
(2)Large frameworks benefit from
serializable/storable objects which contain both
functionality and modifiable values. S4 stores
"class" information and R.oo does not upon
"save()"ing, but there are still real hindrances to
"trading" objects, which is -extraordinarily-
important in creating industrial-variety R-based
analysis.
The classical example in my mind is the difficulties
in implementing a "visitor" pattern in S4.
(3)The absence of references means for large
datasets and long "analysis flows," there is (1)a
hideous amount of memory used storing each predecessor
analysis or (2)there are awkward "references" that
I've seen used like storing the name of the reference
object in a data slot.
I find the use of environments in R.oo as opposed to
the glorified LISTSXP of S4 to be a satisfying way
around this.
S4 is a nice step forward. But R should be open to
further evolution. The design choices for S4 and the
reasons behind abandoning OOP have never been
adequately justified in my knowledge. Instead most
inquiries have been met by a Sphinx-like silence by
the core community.
But the hindrances faced by our friend Ali are
common, and even in packages maintained by experienced
R developers, S4 is implemented shall we say curiously
as per the specs.
Clearly OOP and R.oo are not the final answer. But
some serious discussion about why packages like R.oo
which "layer" onto the standard functional R are
inappropriate is in order.
It would be great to see R emerge from its niche
audience. I believe that would aid statisticians and
programmers. However, a little bit more transparency
and something beyond a categorical "we just don't like
that way of doing things" would go a long way towards
growing the base community of R.
Cheers,
Nathan Whitehouse
Formerly of Baylor College of Medicine.
Ali, maybe we R-core members are not decent enough.
But we strongly believe that we don't want to advocate
yet
another object system additionally to the S3 and S4
one,
and several of us have given talks and classes, even
written
books on how to do "decent" object oriented
programming
`just' with the S3 and/or S4 object system.
No need of additional "oo" in our eyes.
Your main problem is that you assume what "oo" means
{which may
well be true} but *additionally* you also assume that
OO has to
be done in the same way you know it from Python, C++,
or Java..
Since you are new, please try to learn the S4 way,
where methods belong to (generic) functions more than
to classes in some way, particularly if you compare
with other
OO systems where methods belong entirely to classes.
This is NOT true for R (and S-plus) and we don't want
this to
change {and yes, we do know about C++, Python,
Java,... and
their way to do OO}.
Please also read in more details the good advice given
by Tony
Plate and Sean Davis.
Martin Maechler,
ETH Zurich
Nathan Whitehouse
nlwhitehouse@yahoo.com
One important thing to remember, which I think some more experienced programmers may forget, is that R is two things---a programming language and an *interactive* system for statistics and graphics. Maintaining the "interactive-ableness" of R may have imposed certain design choices. I personally think the current S4 system of generics/methods is quite suitable for both the "programming" and "interactive" sides of R. Just $0.02. -roger Nathan Whitehouse wrote:> Hi, > A few comments from a fairly experienced R user who > worked for several years on a R-based bioinformatics > analysis framework. > > I don't want to misrepresent anyone's views, but... > > There are real disadvantages to the > "objects-as-C-structs" and functions/methods which > "mutate" based on argument type. i.e. S4. > > (1)Novices simply don't understand it. Students are > trained in "standard" object-oriented technique and > this wonkish offshoot(puritanical functional > programming) just increases the information costs to > using R and thus decreases the demand. > > (2)Large frameworks benefit from > serializable/storable objects which contain both > functionality and modifiable values. S4 stores > "class" information and R.oo does not upon > "save()"ing, but there are still real hindrances to > "trading" objects, which is -extraordinarily- > important in creating industrial-variety R-based > analysis. > The classical example in my mind is the difficulties > in implementing a "visitor" pattern in S4. > > (3)The absence of references means for large > datasets and long "analysis flows," there is (1)a > hideous amount of memory used storing each predecessor > analysis or (2)there are awkward "references" that > I've seen used like storing the name of the reference > object in a data slot. > I find the use of environments in R.oo as opposed to > the glorified LISTSXP of S4 to be a satisfying way > around this. > > S4 is a nice step forward. But R should be open to > further evolution. The design choices for S4 and the > reasons behind abandoning OOP have never been > adequately justified in my knowledge. Instead most > inquiries have been met by a Sphinx-like silence by > the core community. > > But the hindrances faced by our friend Ali are > common, and even in packages maintained by experienced > R developers, S4 is implemented shall we say curiously > as per the specs. > Clearly OOP and R.oo are not the final answer. But > some serious discussion about why packages like R.oo > which "layer" onto the standard functional R are > inappropriate is in order. > > It would be great to see R emerge from its niche > audience. I believe that would aid statisticians and > programmers. However, a little bit more transparency > and something beyond a categorical "we just don't like > that way of doing things" would go a long way towards > growing the base community of R. > > Cheers, > Nathan Whitehouse > Formerly of Baylor College of Medicine. > > Ali, maybe we R-core members are not decent enough. > But we strongly believe that we don't want to advocate > yet > another object system additionally to the S3 and S4 > one, > and several of us have given talks and classes, even > written > books on how to do "decent" object oriented > programming > `just' with the S3 and/or S4 object system. > > No need of additional "oo" in our eyes. > Your main problem is that you assume what "oo" means > {which may > well be true} but *additionally* you also assume that > OO has to > be done in the same way you know it from Python, C++, > or Java.. > > Since you are new, please try to learn the S4 way, > where methods belong to (generic) functions more than > to classes in some way, particularly if you compare > with other > OO systems where methods belong entirely to classes. > This is NOT true for R (and S-plus) and we don't want > this to > change {and yes, we do know about C++, Python, > Java,... and > their way to do OO}. > > Please also read in more details the good advice given > by Tony > Plate and Sean Davis. > > Martin Maechler, > ETH Zurich > > > > Nathan Whitehouse > nlwhitehouse@yahoo.com > > ______________________________________________ > R-devel@stat.math.ethz.ch mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >-- Roger D. Peng http://www.biostat.jhsph.edu/~rpeng/
Hi Nathan, regarding the use of environments as the basis of objects, note that in R 2.1.0 the CRAN 'proto' package provides a facility for object oriented programming that uses environments as the underlying implementation. Unlike the OO models discussed here, it is based on the prototype model of object oriented programming which is one in which classes are not an atomic concept (though it is powerful enough to readily express them if one wants). Thomas Petzoldt
On Apr 21, 2005, at 9:37 AM, Nathan Whitehouse wrote:> > > (1)Novices simply don't understand it. Students are > trained in "standard" object-oriented technique and > this wonkish offshoot(puritanical functional > programming) just increases the information costs to > using R and thus decreases the demand.The obvious solution here is to avoid the phrase "object oriented," since that apparently means "acts like Java" these days.> > (2)Large frameworks benefit from > serializable/storable objects which contain both > functionality and modifiable values. S4 stores > "class" information and R.oo does not upon > "save()"ing, but there are still real hindrances to > "trading" objects, which is -extraordinarily- > important in creating industrial-variety R-based > analysis. > The classical example in my mind is the difficulties > in implementing a "visitor" pattern in S4.I'm not sure what your complaint about serialization is exactly, serialization is just a way of storing data---its not like Java serialization is actually putting *code* into data objects or anything, so S4's method of saving objects is more or less equivalent. Yes, you have to have the class definition around to get the object back in a reasonable way, but this is true of any language. As for the visitor pattern, the need to implement the visitor pattern is actually a hack needed for single dispatch object systems to overcome that limitation (typically implementing some sort of double dispatch system). This is a classical example of why you really want S4's style of OO and NOT GangOfFour style OO not the other way 'round. You simply implement the methods directly with a signature of length 2 instead of a signature of length 1.> > (3)The absence of references means for large > datasets and long "analysis flows," there is (1)a > hideous amount of memory used storing each predecessor > analysis or (2)there are awkward "references" that > I've seen used like storing the name of the reference > object in a data slot. > I find the use of environments in R.oo as opposed to > the glorified LISTSXP of S4 to be a satisfying way > around this.True, though this has little to do with objects per-se, it has to do with memory management semantics that exist independently of the object system. Frankly, for large datasets you really want to be doing your analytics in some sort of database but weaning people from Excel has proven to be even more daunting than convincing them that "object oriented" is like "vehicular transportation"---it comes in many forms.> > S4 is a nice step forward. But R should be open to > further evolution. The design choices for S4 and the > reasons behind abandoning OOP have never been > adequately justified in my knowledge. Instead most > inquiries have been met by a Sphinx-like silence by > the core community.Abandoning OOP how? S4 is just as object oriented (more so) than S3 and is certainly as object based as Java or C++. Sure it doesn't really act like the Java/C++ style of OO, but to paraphrase the famous Alan Kay quote, "I coined the term object oriented and I sure wasn't thinking of C++ when I did."> > But the hindrances faced by our friend Ali are > common, and even in packages maintained by experienced > R developers, S4 is implemented shall we say curiously > as per the specs. > Clearly OOP and R.oo are not the final answer. But > some serious discussion about why packages like R.oo > which "layer" onto the standard functional R are > inappropriate is in order. > > It would be great to see R emerge from its niche > audience. I believe that would aid statisticians and > programmers. However, a little bit more transparency > and something beyond a categorical "we just don't like > that way of doing things" would go a long way towards > growing the base community of R. > > Cheers, > Nathan Whitehouse > Formerly of Baylor College of Medicine. > > Ali, maybe we R-core members are not decent enough. > But we strongly believe that we don't want to advocate > yet > another object system additionally to the S3 and S4 > one, > and several of us have given talks and classes, even > written > books on how to do "decent" object oriented > programming > `just' with the S3 and/or S4 object system. > > No need of additional "oo" in our eyes. > Your main problem is that you assume what "oo" means > {which may > well be true} but *additionally* you also assume that > OO has to > be done in the same way you know it from Python, C++, > or Java.. > > Since you are new, please try to learn the S4 way, > where methods belong to (generic) functions more than > to classes in some way, particularly if you compare > with other > OO systems where methods belong entirely to classes. > This is NOT true for R (and S-plus) and we don't want > this to > change {and yes, we do know about C++, Python, > Java,... and > their way to do OO}. > > Please also read in more details the good advice given > by Tony > Plate and Sean Davis. > > Martin Maechler, > ETH Zurich > > > > Nathan Whitehouse > nlwhitehouse@yahoo.com > > ______________________________________________ > R-devel@stat.math.ethz.ch mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >--- Byron Ellis (ellis@stat.harvard.edu) "Oook" -- The Librarian