Peter Dalgaard BSA wrote:
>
> John Chambers <jmc@research.bell-labs.com> writes:
>
> > Would there be a problem with a "fix" in which the environment was left
> > unduplicated, but environments with attributes are "duplicated" by
> > creating a copy of the attribute list, but with the copy still pointing
> > to the same environment?
> >
> > If that is not possible, it would be good to have another datatype that
> > had roughly those properties. Otherwise, it's difficult to build on
> > this datatype in designing new classes.
> >
> > (The same issue applies to other types, such as external pointers.)
>
> I've been wrapping such environments in lists, as in
>
> > tclVar
> function (init = "")
> {
> n <- evalq(TclVarCount <- TclVarCount + 1, .TkRoot$env)
> name <- paste("RTcl", n, sep = "")
> l <- list(env = new.env())
> assign(name, NULL, envir = l$env)
> reg.finalizer(l$env, function(env) tkcmd("unset", ls(env)))
> class(l) <- "tclVar"
> tclvalue(l) <- init
> l
> }
>
> where the list(env = new.env()) construct is to avoid sticking a class
> directly on "env".
>
> What you're suggesting would seem to have the same effect, i.e. the
> environment gets effectively embedded in a structure on which you can
> set attributes. It does sound like it could work.
For class-related work, embedding in a list (yes, I do that too) has
somewhat the wrong message, because now the object appears to extend
"list", whereas the intended model is that it extends "environment".
The distinction isn't all academic, because one would like to avoid
list-style computations for "[", etc, which are pretty much guaranteed
to cause trouble.
>
> I'm just a little worried whether it would be clear enough to the end
> user what is going on, or whether we'd just be compounding problems of
> duplications that don't duplicate...
My personal need is for something that acts as a reference (aka
database, object table, etc.) The understanding is that setting named
elements in this object works as for a reference--all copies see the
changes. If the object can otherwise behave in standard "S language"
semantics, programming will be more straightforward.
For now, I use a list containing an environment, but eventually
something more direct will likely be needed.
>
> BTW, this was never a bug...
OK, but as Henrik's mail suggested, users get unpleasant suprises from
trying to treat environments as ordinary objects.
>
> --
> O__ ---- Peter Dalgaard Blegdamsvej 3
> c/ /'_ --- Dept. of Biostatistics 2200 Cph. N
> (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
> ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907
--
John M. Chambers jmc@bell-labs.com
Bell Labs, Lucent Technologies office: (908)582-2681
700 Mountain Avenue, Room 2C-282 fax: (908)582-3340
Murray Hill, NJ 07974 web: http://www.cs.bell-labs.com/~jmc
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel 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-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._