Call vec_restore() on original objects, call vec_proxy() before operating #316
Conversation
krlmlr
changed the title
| @@ -198,5 +198,5 @@ vec_cast.character.pillar_char <- function(x, to, ...) { | |||
| } | |||
| #' @export | |||
| vec_cast.pillar_char.character <- function(x, to, ...) { | |||
| vec_restore(x, to) | |||
| vec_restore(vec_proxy(x), to) | |||
There was a problem hiding this comment.
hmm actually in this case this doesn't make much of a difference since cast methods are not inherited. So you're guaranteed to get a bare character. Sorry for misleading you here.
| @@ -185,7 +185,7 @@ vec_arith.pillar_num <- function(op, x, y, ...) { | |||
| vec_arith.pillar_num.default <- function(op, x, y, ...) { | |||
| "!!!!DEBUG vec_arith.pillar_num.default(`v(op)`)" | |||
| stopifnot(is.numeric(x), is.numeric(y)) | |||
| out <- vec_arith_base(op, x, y) | |||
| out <- vec_arith_base(op, vec_proxy(x), vec_proxy(y)) | |||
There was a problem hiding this comment.
Not sure this is quite right, but I don't have any better advice for generic vec_arith() at the moment. Since you check for is.numeric() above, it feels a bit unnecessary to take the proxy because you're restricting the inputs to have numeric storage.
Also conceptually there is no general guarantee that vec_proxy() is the adequate numeric storage for arithmetic operations. For instance the proxy might be a data frame (record type) and the numeric storage might be in a column of that data frame. For the moment though, we don't have anything better in vctrs.
.