jonkeane commented on a change in pull request #12324:
URL: https://github.com/apache/arrow/pull/12324#discussion_r806894046
##########
File path: r/R/array.R
##########
@@ -216,6 +216,76 @@ Array$create <- function(x, type = NULL) {
#' @include arrowExports.R
Array$import_from_c <- ImportArray
+
+#' Concatenate zero or more Arrays
+#'
+#' @param ... zero or more [Array] objects to concatenate
+#' @param type An optional `type` describing the desired
+#' type for the final Array.
+#'
+#' @return An [Array]
+#' @export
+#'
+#' @examples
+#' concat_arrays(Array$create(1:3), Array$create(4:5))
+#'
+concat_arrays <- function(..., type = NULL) {
+ dots <- lapply(list2(...), Array$create, type = type)
+
+ if (length(dots) == 0 && is.null(type)) {
+ return(Array$create(logical(), type = null()))
+ } else if (length(dots) == 0) {
+ return(Array$create(logical(), type = null())$cast(type))
+ }
+
+ if (!is.null(type)) {
+ dots <- lapply(dots, function(array) array$cast(type))
+ }
+
+ arrow__Concatenate(dots)
+}
+
+# The c() method uses non-standard dispatch in R
+# and has some peculiarities when multiple types are passed to ....
+# However, with a method defined for all subclasses of Array, it will
+# do what a user expects most of the time.
Review comment:
Hmm, maybe this is idiosyncratic but stuffing the arrays themselves into
a vector seems not quite as bad to me, but I can see how that's (probably) not
what people want.
Then again, even without defining them we get odd behaviors depending on the
order already anyway. This is from an arrow install that is not on this branch:
```
> c( wk::xy(1:2, 1:2), Array$create(1:3))
Error: Can't combine 'wk_rcrd' objects that do not have identical classes.
> c(Array$create(1:3), wk::xy(1:2, 1:2))
[[1]]
Array
<int32>
[
1,
2,
3
]
$x
[1] 1 2
$y
[1] 1 2
```
I'm fine keeping it, either way we should mention in our docs that `c()`
will probably be surprising
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
