lionel-
commented
4 years ago Another example whene composition of proxy and restore would be needed: If we implement names support for record vectors through a special rcrd field.
Open lionel- opened 4 years ago
lionel-
commented
4 years ago Another example whene composition of proxy and restore would be needed: If we implement names support for record vectors through a special rcrd field.
lionel-
commented
4 years ago Restoring the classes that don't implement vec_restore() would prevent accidentally inheriting ptype2 methods via vec_ptype():
vec_ptype2.vctrs_foobar.vctrs_foobar <- function(x, y, ...) x
vec_ptype2(foobar(1), foobar(1, class = "quux"))
#> Error: Can't combine <vctrs_foobar> and <quux>.
vec_restore.vctrs_foobar <- function(x, to, ...) foobar(x)
vec_ptype2(foobar(1), foobar(1, class = "quux"))
#> numeric(0)
#> attr(,"class")
#> [1] "vctrs_foobar"
Data frame restoration is currently weird because we first call restore-default, then dispatch on
vec_restore(), which ends up calling restore-default again.I suspect it makes sense to automatically call restore methods for all classes in reverse order without relying on S3 dispatch. We'd first restore core attributes, then data frame ones, etc. For consistency the proxy methods would also be called (in order this time) automatically. I worry about the efficiency of this scheme though.
Alternatively we could disallow inheritance and force classes to explicitly call their parent methods. It seems like that would introduce too much friction.