[R] A primitive OO in R -- where next?

Muenchen, Robert A (Bob) muenchen at utk.edu
Sun May 16 01:11:48 CEST 2010

Hi All,

This was a very interesting question & I enjoyed reading everyone's
responses. I've played around with it and summarized some of the
variations below.


# A fun example of how a list can store both a function 
# and data for that function. 

# Create a list that contains both a function and some data:

myList <- list(Fun=mean, x=c(1,2,3,4,5))

# Execute the function on the data

# Alternately, put the data into the function call:


# And evaluate it:

eval( as.call(myList) )

# Why does this not work?

myList <- list(Fun=mean, mydata=c(1,2,3,4,5))
eval( as.call(myList) )

# Because "mean" has an "x" argument
# and that does not exist since it's now named "mydata"

myList <- list(Fun=mean, x=c(1,2,3,4,5))
eval( as.call(myList) )

# And how does order affect it?
# Let's put the data first

myList <- list(x=c(1,2,3,4,5), Fun=mean)

# This works fine:

# But look at what as.call tries to do:

# So evaluating it would be nonsense:
eval( as.call(myList) )

>-----Original Message-----
>From: r-help-bounces at r-project.org
[mailto:r-help-bounces at r-project.org]
>On Behalf Of S Ellison
>Sent: Thursday, May 13, 2010 8:07 AM
>To: Ted Harding; r-help at stat.math.ethz.ch
>Subject: Re: [R] A primitive OO in R -- where next?
>R OO is documented for S3 classes under section 5 (Object-oriented
>programming) in the R language definition.
>I guess the issue is somewhat philosophial as to how you use it.
>R philosophy _mostly_ separates data from operations on data, so the OO
>model provides classes for data and essentially separate methods that
>apply to those classes. This is the kind of model sometimes called a
>'visitor pattern'. An alternative is to include operations on the data
>within the data object, which sometimes has advantages if you want to
>simplify the look of code for things like display (instead of a display
>method for each class, one effectively sends a mesage to any object of
>the form "display yourself here"). In practice, of course, one ends up
>writing class-specific operations code; the difference is pretty much
>where it's stored.
>On balance there seems to me a rationale for a statistician to separate
>data from the operations formed on it; one collects and curates data
>carefuly, so it as a kind of lifecycle of its own that is unrelated to
>mathematical operations performed on it.
>But I have allowed _data_ objects to include functions or at least
>function names when it is a necessary part of the description of the
>data. For example, in some of our interlaboratory studies labs give
>uncertainty information in the form of a variance or interval, but may
>additionally tell us what the assumed distribution is (eg Normal, t,
>lognormal etc). It then makes sense to have the distribution as part of
>the data. For these functions, the root name (norm, t, etc)_ suffices
>conjunction with do.call, but to generalise completely, one can
>allowing a user to specify the distribution as (say) some arbitrary
>density function or density/probability family. (It's pretty rare that
>we'd need that, but hey - thinking ahead and all that). That would
>generate data which in part consisted of a function describing the
>(assumed) associated distribution.
>Steve Ellison
>>>> Ted Harding <Ted.Harding at manchester.ac.uk> 12/05/2010 22:48:17 >>>
>Greetings All,
>Out of curiosity, I've just done a very primitive experiment:
>  Obj <- list(Fun=sum, Dat=c(1,2,3,4))
>  Obj$Fun(Obj$Dat)
>  # [1] 10
>That sort of thing (much more sophisticated) must be documented
>mind-blowingly somewhere. Where?
>Where I stand right now: The above (and its immediately obvious
>generalisations, like Obj$Fun<-cos) is all I know about it so far.
>E-Mail: (Ted Harding) <Ted.Harding at manchester.ac.uk>
>Fax-to-email: +44 (0)870 094 0861
>Date: 12-May-10                                       Time: 22:48:14
>------------------------------ XFMail ------------------------------
>R-help at r-project.org mailing list
>PLEASE do read the posting guide
>and provide commented, minimal, self-contained, reproducible code.
>This email and any attachments are confidential. Any
>R-help at r-project.org mailing list
>PLEASE do read the posting guide http://www.R-project.org/posting-
>and provide commented, minimal, self-contained, reproducible code.

More information about the R-help mailing list