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.
Cheers, Bob # 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)) myList # Execute the function on the data myList$Fun(myList$x) # Alternately, put the data into the function call: as.call(myList) # 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: myList$Fun(myList$x) # But look at what as.call tries to do: as.call(myList) # So evaluating it would be nonsense: eval( as.call(myList) ) >-----Original Message----- >From: r-help-boun...@r-project.org [mailto:r-help-boun...@r-project.org] >On Behalf Of S Ellison >Sent: Thursday, May 13, 2010 8:07 AM >To: Ted Harding; r-h...@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 in >conjunction with do.call, but to generalise completely, one can consider >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.hard...@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. > >Ted. > >-------------------------------------------------------------------- >E-Mail: (Ted Harding) <ted.hard...@manchester.ac.uk> >Fax-to-email: +44 (0)870 094 0861 >Date: 12-May-10 Time: 22:48:14 >------------------------------ XFMail ------------------------------ > >______________________________________________ >R-help@r-project.org mailing list >https://stat.ethz.ch/mailman/listinfo/r-help >PLEASE do read the posting guide >http://www.R-project.org/posting-guide.html >and provide commented, minimal, self-contained, reproducible code. > >******************************************************************* >This email and any attachments are confidential. Any use...{{dropped:8}} > >______________________________________________ >R-help@r-project.org mailing list >https://stat.ethz.ch/mailman/listinfo/r-help >PLEASE do read the posting guide http://www.R-project.org/posting- >guide.html >and provide commented, minimal, self-contained, reproducible code. ______________________________________________ R-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
