[Rd] Plans for tighter integration of reference classes in R.

John Chambers jmc at r-project.org
Sun Oct 24 17:54:16 CEST 2010


On 10/24/10 2:53 AM, Vitalie S. wrote:
>
> Thank you for the answer, John.
>
> John Chambers<jmc at r-project.org>  writes:
>> 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.
>
> But, how about parent.env() functionality? The "S4" envelope is lost:
>
>> setClass("myenv", contains = "environment")
> [1] "myenv"
>> env<- new("myenv")
>> envp<- new("myenv")
>> parent.env(env)<- envp
>> parent.env(env)
> <environment: 0247a650>

If you're talking about new R code, consider writing methods for 
parent.env() or for environment().

If you mean reprogramming the internals of the evaluator, not a chance 
in the foreseeable future.

>
> Here I have in mind, as an application, the "prototype" programing paradigm
> (akin to JavaScript, also implemented in R's proto package).
>
> If environment manipulation functions would not strip the "S4" envelope from
> environments, a considerably wider scope for implementation of "foreign"
> programing paradigms would open up. All, by using the "existing techniques"
> already available in S4 system.
>
> Proto package makes it possible by using S3 classes, because they are not
> striped away. Currently I am struggling to build a prototype based system, similar to
> proto,  but in S4 framework. With all the advantages of S4, I am still doubting
> that I made a right decision.
>
> Thanks,
> Vitalie.
>
>> ... (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 at 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 at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel>
>>
>> 	[[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



More information about the R-devel mailing list