  For reference classes (and other R code) it's important to distinguish 
the application program interface from the implementation.  Anyone is 
welcome to explore the implementation, but we reserve the right to 
change that, particularly with a new feature in the language.

The draft API for reference classes is the ?ReferenceClasses 
documentation page at this stage.

Second point first:  The actual environment of a function is tightly 
bound to low-level implementation at the C level.  Only a _really_ 
strong practical argument would even tempt us to change that, such as by 
going away from the requirement that the type of the environment be 
ENVSXP.   (As mentioned in another thread, one point in favor of 
reference classes is that they have not messed with internals of R 
evaluation, just used existing techniques.)

The API  says nothing about what the environment of a reference method 
is, only that you aren't allowed to use any of the other R tricks that 
depend on the environment, such as generic functions.

Assigning attributes directly to an environment is a bad idea, as 
discussed in the past on this list.  That's why we went to the S4 
mechanism for subclasses of environments.

As for .self, the documentation says that the "entire object can be 
referred to in a method by the reserved name .self|"|.  That's a bit 
vague, and it's possible that one could update the slots of .self as 
part of slot assignment, but absent a serious example, it may be better 
to just clarify the documentation.


On 10/23/10 5:43 AM, Vitalie S. wrote:
> Hello Everyone!  Here are a couple of thought/questions on refClasses
> integration in R core functionality.
>
> First, coexistence with S4:
>
>> X<- setRefClass("classX", fields = c("a", "b"),
> +                  representation = list(c = "character"))
>> x<- X$new()
>> x@c<- "sss"
>> x
> An object of class "classX"
> <environment: 059bf6a4>
> Slot "c":
> [1] "sss"
>
> The above is cool, S4 and refClasses apparently live happily together.
> But,
>
>> x$.self
> An object of class "classX"
> <environment: 059bf6a4>
> Slot "c":
> character(0)
>
> This is not a surprise, taking into account the copping paradigm of R.
> Are there any plans to tighten S4<>refClasses integration? Or it's just not a
> good idea to mix them as in the above example?
>
>
> Second, R core integration (this bothers me much more):
>
>> X$methods(m = function(t) a*t)
>> environment(x$m)
> <environment: 059bf6a4>
>
> environment(..) does not return the refObject but the basic type. I assume that
> it is the same with other core functionality. Usage of refObjects as parent.env
> is also probably precluded in the similar way (don't have a patched R, so can
> not test yet).
>
> Would it be possible, some day, to use refObjects as parent.env or function's
> environment  without "loosing the class"?
>
> Parenthetically, the attributes of an object (including S3 classes) are not lost:
>
>> env<- structure(new.env(), a1 = "fdsf", class = "old_class")
>> tf<- function(x)x
>> environment(tf)<- env
>> environment(tf)
> <environment: 056570a0>
> attr(,"a1")
> [1] "fdsf"
> attr(,"class")
> [1] "old_class"
>> class(environment(tf))
> [1] "old_class"
> Thanks,
> Vitalie.
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

	[[alternative HTML version deleted]]

