paleolimbot commented on code in PR #39:
URL: https://github.com/apache/arrow-nanoarrow/pull/39#discussion_r960599155
##########
r/NAMESPACE:
##########
@@ -1,4 +1,33 @@
# Generated by roxygen2: do not edit by hand
+S3method(as_nanoarrow_array,Array)
+S3method(as_nanoarrow_array,ChunkedArray)
+S3method(as_nanoarrow_array,RecordBatch)
+S3method(as_nanoarrow_array,Table)
+S3method(as_nanoarrow_array,default)
+S3method(as_nanoarrow_array_stream,RecordBatchReader)
+S3method(as_nanoarrow_array_stream,default)
+S3method(as_nanoarrow_array_stream,nanoarrow_array_stream)
+S3method(as_nanoarrow_schema,DataType)
+S3method(as_nanoarrow_schema,Field)
+S3method(as_nanoarrow_schema,Schema)
+S3method(as_nanoarrow_schema,nanoarrow_schema)
Review Comment:
Yeah, `as_nanoarrow_anything()` is a mouthful and is mostly because I
couldn't think of anything better. I suppose the namespace `na` instead of
`nanoarrow` could work, too, but but it's also mostly developer facing and
users shouldn't really have to know these classes/functions exist.
The reason why I didn't use `to_nanoarrow()` is that each S3 class really
does need its own coerce method. I used them in geoarrow to do stuff like:
```r
do_something_cool <- function(array) {
array <- as_nanoarrow_array(array)
.Call(some_c_function, array)
}
```
(i.e., a similar way that we use `arrow::as_arrow_array()` although the
nanoarrow array doesn't have any user-facing conveniences like `[` subsetting
or other vector-ish S3 generics).
The `as_nanoarrow_array()` / `from_nanoarrow_array()` bit is inspired by
`vctrs::vec_restore()` and `vctrs::vec_cast()`, which both take a ptype `to`
argument. In arrow we're user-facing and we don't let the user pick what type
of object gets returned from `as.vector()`. In nanoarrow we're
developer-facing, and the ability to do something like
`from_nanoarrow_array(array, double())` (or recursively,
`from_nanoarrow_array(array, data.frame(x = double())`) makes R type stability
easier. readr does something like this, too with its `cols(x = col_double())`.
Importantly, this also lets an extension package author define the
`as_nanoarrow_array()` and `from_nanoarrow_array()` S3 generics in their own
package and nanoarrow doesn't have to know it exists for
`from_nanoarrow_array(array, data.frame(x = some_extension_type())` to do its
thing.
All of that is a bit esoteric, though, because at the end of the day
`as.data.frame()` will be the entry point for most people most times. The main
thing I like about the `as_()`/`from_()` system is that the S3 object author
decides how or if that conversion takes place, not nanoarrow.
--
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]
