John Chambers <j...@r-project.org> writes: >> >> Not internals of the evaluator, the .environment class. >> Something like: >> - move the .self into a super-class of envRefClass (in this case >> .environment), >> - make the method for `...@` for .environment, such that any update of the >> slots of the object will update the .self, making it virtually a mirror >> of the >> object. >> - make functions like parent.env and environment recognize the .self and >> return it instead of the internal environment object (writing methods >> would be probably >> quite an overhead). > > I'm sorry, this is not likely to happen soon, if you expect the core > developers to do it for you. If you want to > implement something like you suggest via methods for your classes and find it > works well, we can consider > implementing related code for the core .environment class. > > Whether you think the overhead of _writing_ the methods is large or not, the > way such development in R works best > is that those interested in new features implement them; particularly useful > or attractive features may be absorbed > into the core later if that makes sense. > > Meanwhile, the overhead of _using_ methods for these functions (i.e., the > need to dispatch methods for the newly > generic functions) will not be passed on to other applications that subclass > environment. > :)) I was so enthusiastic about the idea that _using_ and _writing_ had the same meaning for me. Of course I meant _using_ there. Writing should be easy.
Thanks, Vitalie. ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
