On Sun, Apr 25, 2010 at 1:09 PM, Duncan Murdoch <murdoch.dun...@gmail.com> wrote: > On 24/04/2010 1:15 PM, Christopher Brown wrote: >> >> I looked through the documentation and the mailing lists and could not >> find an answer to this. My apologies if it has already been answered. >> If it has, a pointer to the relevant discussion would be greatly >> appreciated. >> > > Environments are unusual in that they are reference objects: if e is an > environment, and you assign f <- e, then f refers to the same object as e > does. This is unusual in R, where most objects are copied on assignment > (logically, not always physically). It means that attributes on > environments behave strangely: if you put an attribute on e and remove the > same attribute from f, it is gone from e too. We've discussed removing the > possibility of putting attributes on environments (just as you can't put > attributes on NULL), but haven't done so yet. > > What you should do if you want to use an environment in the way you're using > it is to put it in a container. For S4, that could mean using an > environment as a slot, or inheriting from an object like list(e), rather > than directly from e.
I can confirm these reported issues. FYI, what Duncan is suggesting is exactly the design behind the Object class (encapsulates an environment) in the R.oo package. The difference is that it is working with S3. It's been working flawlessly for > 9 years. Others have had idea to do the same but with S4, but I'm not sure if that ever took of. /Henrik (R.oo author) > > Duncan Murdoch >> >> Creating S4 classes containing environments exhibits unexpected >> behavior/features. These have a different in two ways: >> >> 1) slotName for the data: ".xData" instead of ".Data" and do not respond >> to the >> 2) Response to the is.* function seems to indicate that the object >> does not know of its inheritance. ( Notably, the inherits function >> works as expected. ) >> >> Here is a working illustration: >> >> >>> >>> # LIST >>> setClass( 'inheritList', contains='list') >>> >> >> [1] "inheritList" >> >>> >>> inList <- new( 'inheritList' ) >>> class( inList ) >>> >> >> [1] "inheritList" >> attr(,"package") >> [1] ".GlobalEnv" >> >>> >>> is.list( inList ) # TRUE >>> >> >> [1] TRUE >> >>> >>> slotNames(inList) # ".Data" >>> >> >> [1] ".Data" >> >>> >>> inherits(inList, 'list' ) # TRUE >>> >> >> [1] TRUE >> >>> >>> # ENVIRONMENT >>> setClass( 'inheritEnv', contains='environment' ) >>> >> >> Defining type "environment" as a superclass via class ".environment" >> [1] "inheritEnv" >> >>> >>> inEnv <- new( 'inheritEnv' ) >>> class(inEnv) >>> >> >> [1] "inheritEnv" >> attr(,"package") >> [1] ".GlobalEnv" >> >>> >>> is.environment(inEnv) # FALSE >>> >> >> [1] FALSE >> >>> >>> slotNames(inEnv) # ".xData" >>> >> >> [1] ".xData" >> >>> >>> inherits(inEnv, 'environment' ) # TRUE >>> >> >> [1] TRUE >> >> My questions is whether this behavior is a bug? By design? A work >> around? Etc.? >> >> Thanks kindly for your reply, >> >> Chris >> >> >> the Open Data Group >> http://www.opendatagroup.com >> http://blog.opendatagroup.com >> >> ______________________________________________ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
