[R] Question on closure (lexical scoping) and encapsulation

Peter Dalgaard BSA p.dalgaard at biostat.ku.dk
Tue Jun 13 23:43:09 CEST 2000


Aleksey Naumov <naumov at acsu.buffalo.edu> writes:

> Dear R users,
> 
> I have two related questions about scoping and data encapsulation.
> 
> One is fairly specific - I am looking at "scoping.R" which is used in
> demo(scoping) - it's an example of lexical scoping and encapsulation.
> Where is the 'total' stored? It is not an attribute in 'ross' or
> 'robert'
> however, functions like balance() have access to it.

It's sitting in the environment of the functions associated with ross
& robert. Originally as the argument to open.account.

> Is it more or less like a private class member in C++, so that it's not
> possible to access it from outside of class? Or is it possible to access
> it
> in some way?

Try stuff like

 ls(env=environment(ross$withdraw))
 get("total",env=environment(ross$withdraw))
 evalq(total <- 0, environment(robert$deposit))
 robert$balance() # Rob got robbed!

So it's not entirely like private parts in C++.

> 
> The second one is more general - what is the best way to encapsulate
> some
> user data with an object like a data frame? I'd like to keep a few user
> attributes with a data frame... I can think of 3 possibilities, but I
> don't know if there's a good and reliable standard way:

>     - I tried using attributes(), but found out that subset() gets
> rid of user attributes and didn't see an easy way to reset them on a
> subsetted frame (doing it one by one is not an option, and
> mostattributes() doesn't seem to be there anymore)

It's there (notice that it is "mostattributes<-"), but apparently it
is broken at the moment, or at least it didn't do what I expected..
This would not seem fixable for 1.1.0 on Thursday...

Notice however, that nothing is keeping you from having one attribute
containing several pieces of information, and copying one attribute on
subsetting is not too hard. You can actually have an entire
environment as an attribute. (But notice that environments are like
pointers in C: if you copy one, there's still only one copy of what it
contains.)

>     - Something like the example used in 'scoping.R'

>     - Using class()? Documentation for class() talks about providing
> methods for generic functions, but I didn't see an example of
> accessing user-defined data members/attributes.

I don't think class() will get you anything useful. Something with
environments, maybe. Notice, BTW, now that you're on the topic, the
local() function and friends.

In general, the jury is pretty much still out on how to handle the
kind of construction you seem to desire. Much of the modeling code was
designed for S compatibility and S doesn't have environments in the
same way R does, and several people feel that we're not really
utilizing the potential (then again, others value cross-platform
portability). Jim Lindsey has some ideas in a paper on his
website, and Doug Bates used some other ideas for the nls code. It's
the kind of thing that we really should get around to discussing in a
systematic manner, but tends to be difficult to get a hold on.

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)             FAX: (+45) 35327907
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._



More information about the R-help mailing list