On 5/3/11 2:39 PM, Hadley Wickham wrote:
Part of the motivation for the reference classes was to bring a general OOP
view to R. One can start from some essential concepts of objects and their
properties, inheritance and class definition, as have evolved over a very
long time.
Next, there is a fundamental choice of paradigm between "encapsulated" OOP
as the rest of the world knows it, and "functional" OOP as practiced by S
and R, and a few other languages. While the two paradigms are quite
different, there is no need to view them as opposed. They provide different
advantages and tend to suit different goals--very roughly, functional object
creation and reproducible results versus persistent objects whose properties
one would like to have evolve over time using their encapsulated methods.
My biggest worry with the introduction of reference classes is that
many people will just stick to the style of OOP that they're familiar
with, and not bother to learn the strengths of the generic function
approach.
Well, that says that presenting the choices well is important. Agreed.
But the alternative is (and has been) for people from the "other" OOP
background to hack something using the functional S4/S3 paradigm and
then complain when it doesn't behave as expected. Not really preferable.
As these remarks may suggest, I'm trying to write up this perspective in
some detail. To be continued ....
Are you familiar with "Concepts, Techniques, and Models of Computer
Programming" by van Roy and Haridi? That's what really helped me to
understand the strengths and weaknesses of the various styles of
programming.
Thanks, I wasn't. Yes, interesting similar distinction between
functional and "type" decomposition. An important associated aspect for
us is the distinction between reference objects and "ordinary" R
objects, not AFAICS conveyed by their more abstract treatment.
John
Hadley
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
