Plans for tighter integration of reference classes in R.

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Plans for tighter integration of reference classes in R.

Vitalie S.-2

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.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Plans for tighter integration of reference classes in R.

John Chambers-2
  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.
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Plans for tighter integration of reference classes in R.

Vitalie S.-2

Thank you for the answer, John.

John Chambers <[hidden email]> 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>

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@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.
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel>
>
> [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Plans for tighter integration of reference classes in R.

John Chambers-2
On 10/24/10 2:53 AM, Vitalie S. wrote:

>
> Thank you for the answer, John.
>
> John Chambers<[hidden email]>  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@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.
>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel>
>>
>> [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Plans for tighter integration of reference classes in R.

Vitalie S.-2
John Chambers <[hidden email]> writes:

> On 10/24/10 2:53 AM, Vitalie S. wrote:
>>
>> Thank you for the answer, John.
>>
>> John Chambers<[hidden email]>  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.

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).

This way, envRefClass is not affected, and people will have much nicer time in
programming with subclasses of .environment. Particularly I will be writing my
protoRefClasses happily, and not bother to overwrite core functions:)

>
>>
>> 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@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.
>>>>
>>>> ______________________________________________
>>>> [hidden email] mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel>>>
>>> [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Plans for tighter integration of reference classes in R.

John Chambers-2


On 10/24/10 1:43 PM, Vitalie S. wrote:

> John Chambers<[hidden email]>  writes:
>
>> On 10/24/10 2:53 AM, Vitalie S. wrote:
>>>
>>> Thank you for the answer, John.
>>>
>>> John Chambers<[hidden email]>   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.
>
> 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.



>
> This way, envRefClass is not affected, and people will have much nicer time in
> programming with subclasses of .environment. Particularly I will be writing my
> protoRefClasses happily, and not bother to overwrite core functions:)
>
>>
>>>
>>> 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@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.
>>>>>
>>>>> ______________________________________________
>>>>> [hidden email] mailing list
>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel>>>
>>>> [[alternative HTML version deleted]]
>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Plans for tighter integration of reference classes in R.

Vitalie S.-2

John Chambers <[hidden email]> 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.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel