t-kalinowski
commented
8 months ago This is a draft implementation of prop<- in C. It is failing to build on older R versions, and isn't particularly tidy yet.
There are some open questions about what "should" happen when a custom property setter is provided that merit discussion.
- When, and how often, should
validate()be called fromprop<-in the case of a custom propertysetter()? - Are there any circumstances where a
prop<-()call within a customsetter()should invoke another customsetter()? E.g., when setting a different propertyname, or setting a property of the same name on a differentobject(i.e., notself). Isprop<-allowed to recursively call a customsetter()under any circumstances?
For (1), there is currently a snapshot test that looks like this:
library(S7)
# snapshot title: "validates once after custom setter"
custom_setter <- function(self, value) {
self@x <- as.double(value)
self
}
foo2 <- new_class(
"foo2",
properties = list(x = new_property(class_double, setter = custom_setter)),
validator = function(self) {
print("validating")
character()
}
)
obj <- foo2("123")
#> [1] "validating"
obj@x <- "456"Note that the last expression, obj@x <- "456", did not invoke the validator. This seems inconsistent with the docs.
Is this a bug in the current implementation of prop<-, or should the docs be updated to clarify that a custom property setter is responsible for make sure the returned object is valid?
For (2), I've added a snapshot test for prop<- that fails with the current R implementation of prop<- on the main branch.
The draft implementation in C (this PR) doesn't infinitely recurse, but it's not clear to me that this current behavior is correct either.
library(S7)
chattily_sync_ab <- function(self, value) {
cat("Starting syncup with value:", value, "\n")
a_value <- paste0("a_", value)
b_value <- paste0("b_", value)
cat(sprintf('setting @a <- "%s"\n', a_value))
self@a <- a_value
cat(sprintf('setting @b <- "%s"\n', b_value))
self@b <- b_value
self
}
foo <- new_class("foo", properties = list(
a = new_property(setter = chattily_sync_ab),
b = new_property(setter = chattily_sync_ab)
))
obj <- foo()
#> Starting syncup with value:
#> setting @a <- "a_"
#> setting @b <- "b_"
#> Starting syncup with value: b_
#> setting @a <- "a_b_"
#> setting @b <- "b_b_"
#> Starting syncup with value:
#> setting @a <- "a_"
#> Starting syncup with value: a_
#> setting @a <- "a_a_"
#> setting @b <- "b_a_"
#> setting @b <- "b_"
obj@a <- "val"
#> Starting syncup with value: val
#> setting @a <- "a_val"
#> setting @b <- "b_val"
#> Starting syncup with value: b_val
#> setting @a <- "a_b_val"
#> setting @b <- "b_b_val"We should also clarify when validate() is supposed to be called in (2) as well.
(3) (bonus). The edge case of a custom setter setting a property on something other than self also probably merits some discussion.
My current intuition for how to avoid infinite recursion but still allow a setter() to implicitly call setter() on other objects or properties is to attach an attribute to object with a (growable) list of property names to avoid recursively calling custom setters on. I.e., temporarily mark the object and property as non-active-setter-callable,
a more narrow cousin to the .should_validate attr we attach with validate_eventually().
Something like this (but w/ append/pop semantics):
attr(object, "dont_call_prop_setter") <- prop_name
setter(object, value)
attr(object, "dont_call_prop_setter") <- NULL
hadley
DavisVaughan
This PR moves
prop<-to C. As part of this, there are some changes in behavior that are worth highlighting.The mechanism by which
prop<-avoids infinitely recursing on custom setters is different now.setter()prop name in a global variable, and use that to avoid calling a setter on another property of the same name. This failed if there were two custom setters calling each other, or if a setter set a property by the same name on a different object.prop<-setsattr(object, ".setting_prop") <- pairlist(prop_name)before calling the custom setter. In the case of recursive setters, theprop_names are appended to the pairlist. This attribute is consulted byprop<-when deciding whether to call a custom setter.Previously,
validate(object)was not called if a customsetter()was invoked. This I think was a bug/regression inprop<-, and is now fixed.validate(object)is called on the object returned by thesetter(), ifprop<-was called withcheck = TRUE(the default).