bkietz commented on issue #599: URL: https://github.com/apache/arrow-nanoarrow/issues/599#issuecomment-2318556799
IIUC sparrow is designed for consumption exclusively as a C++20 library. Although this makes their API seriously expressive, it makes the library less accessible as an ingredient in other APIs. As I understand it, `nanoarrow`'s priority is ease of consumption of the core C API; a primary example would be its own R and python bindings: - (as you said) C APIs are accessible to any binding language's FFI - C being entirely unopinonated about lifetimes allows the binding language unambiguous control over objects (no negotiating with a shared_ptr) - likewise binding languages are fully capable of expressing iterators and other conveniences by calling C functions directly (without negotiating intervening C++ equivalents) - in process built with more than a single binding language, the shared foundation of basic objects makes interoperation between the two languages far simpler to negotiate. In light of this, I think strictly framing `nanoarrow`'s C++ layer as just one more higher-level language binding makes the most sense. I think it's a goal to provide a usefully, predictably uniform kernel of functions across languages in the same original spirit of the C-ABI itself, almost like an extension of the C-ABI. This is in contrast to `sparrow` which AFAICT is intended to wrap and use the C-ABI for ergonomic and idiomatic C++20 usage. > We are a C library, though, and the C library tests will need to have some C library calls in them I'm hesitant to agree with this since it feels that the implication is once again that the unit tests should contain mostly recognizable usages of the API. Instead I'd say test writers should have a free hand to use and extend C++ helpers as needed, so that the only C library call which appears in a given unit test is the function exercised by the test. For example, no unit test in ipc/ should need to call `ArrowSchemaInit*`; that's tested elsewhere and the test writers should use something less verbose to get their schemas. > this might be useful (as janky as it is) https://github.com/apache/arrow-adbc/blob/main/docs/source/ext/adbc_cookbook.py I love this. I'll definitely consider borrowing it for writing nanoarrow examples -- 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]
