Thanks Roger, Duncan, Henrik and John: First, Roger. Yes this works as expected:
inherits( inEnv, 'environment' ) Thanks for pointing that out. Duncan, I maintain the hash packages, which provides perl-hash / python-dictionary wrapper around the environment. A very early implementation did as you said. It encapsulated the environment in a slot and I wrote all the various accessors and decorators. The problem with that was poor performance ... well not poor exactly, but my aims are to provide hash as a basic data structure and as such should be close to core as possible. I have thought about trying to tie-in Judy hash, but don't really have the time for that type of an under-taking yet. So I am excited to have the ability to directly inherit from environements. It works great, just with the inconsitencies that I pointed out. Henrik, I have loved and used R.oo for a number of years. It is brilliant, but I too would like to see an S4 OO framework. One of my projects on the backburner is implementing Perl's Moose for R. Finally John, Thanks, as always, for the succinct explanation. Regards, Chris Christopher Brown Open Data http://www.opendatagroup.com http://blog.opendatagroup.com On Sun, Apr 25, 2010 at 3:38 PM, John Chambers <j...@r-project.org> wrote: > In addition to Duncan Murdoch's explanation, this is discussed in the > documentation for "Classes" (briefly): > ..... > > Extending a basic type this way allows objects to use old-style code for > the corresponding type as well as S4 methods. Any basic type can be used for > .Data, but a few types are treated differently because they do not behave > like ordinary objects; for example, "NULL", environments, and external > pointers. Classes extend these types by using a specially named slot, itself > inherited from an internally defined S4 class. Inheritance from the > nonstandard object type then requires an actual computation, rather than the > "simple" inclusion for other types and classes. The intent is that > programmers will not need to take account of the mechanism, but one > implication is that you should not explicitly use the type of an S4 object > that extends an arbitrary object type. Use is and similar functions instead. > > ....... > > > The code for is.environment() is presumably using the type, whereas > inherits() takes account of the indirect mechanism. > > Generally, you should be able to deal with inheritance from environments in > a natural way. > > John > > > > On 4/24/10 10:15 AM, 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. >> >> 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 >> >> [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
