Allow `class_environment` as parent.

[ltuijnder]

Currently class_environment as parent is disallowed by: #290 to fix the issue: #253 .

But environments are really useful objects in R. As they are the only object that support in place updating. It would be nice if we can have this type of object participate in the S7 dispatch system and define validation rules on environments.

I opened a similar issue before where I requested the feature of allowing in-place updates for S7 properties: #525. But I can understand if that feature gets rejected duo complexity. Though, I still think it is valid to resurrect the possibility to create a S7 environment object directly. And hence I am creating this separate issue to distance it from #525.

The problem with environments:

As explained in the issue #253, the root cause with environments is when calling S7_data() a function a zap_attr removes (among others) the attributes: "class" and "S7_class" . Eg: attr(my_s7_env_obj, 'class') <- NULL.

But duo the unique nature of environments, this attribute property update is done in place and thus the S7 nature is lost permanently.

How could we fix it?

1. Special case class_environment. Since environments in R are the ONLY base objects that exhibit this behavior we could simply special case it in our logic. There are then still different options how we want to deal with the environment when S7_data is called.
   a. Disallow it for environments. In a sense we move the "disallowing" of it being a parent to just disallowing it being called on S7_data().
   b. Allow it but document it that it will destroy the S7 nature and this it a one way trip. One is still free to re instantiate the "S7" object by calling the constructor again with the backed-up S7 properties (provided the user did back-up the properties this would also need to get documented).
   c. Allow it but document that a COPY is returned. Though I am not sure if this would be useful because the cool thing about environments is that they support in place updating. So if you then do further manipulations on this copy one needs to remember to update the original S7 object also. But maybe there are use cases where it can be handy.
2. Rework S7_data and zap_attr mechanism that would support environments. A refactor of this code is needed anyway if want to solve: Should S7 data return S3 objects? #380 . Maybe the rework could also take environments into account.
   • Though I am not sure how such a refactor could look like, duo the fact that there is only 1 copy of an environment and it either has the S7 classes or not.

The above suggestions do assume S7_data is the only place where environments give trouble with the S7 system. It might be other places in the code base do not assume in place attribute updating. But again here I would argue to maybe special case environments. And just document upfront that if you are going to inherit from environments be aware that it behaves differently then the other base objects.

Just as users should be aware in normal R programming that environments are different from the copy-on-write principle that other objects exhibit. So S7 would then just extend that nature of R to its system.

---

Personally, I would not call the S7_data function as I would just interact with the environment via $ and [, [[ methods on the S7 environment object directly. So whatever gets chosen for how to deal with S7_data it would unblock me.