paleolimbot commented on issue #599: URL: https://github.com/apache/arrow-nanoarrow/issues/599#issuecomment-2316630536
Definitely a great point that this is not well defined! A few initial thoughts: > this leads to extremely verbose unit tests and code examples. Things like IPC, ADBC, and integration testing are disproportionately affected here, since they are essentially nanoarrow "users" more so than the nanoarrow C library itself. These are places that there is significant verbosity unrelated to the function being tested (e.g., creating an array to roundtrip through IPC), and where I wish I had things like `ArrayFromJSON()`. We are a C library and C is verbose, but I think the key to all of this is limiting the C-verbosity to the function being tested. > find out whether the C++ layer is seriously used I am aware of `nanoarrow::UniqueXXX` helper usage (Snowflake Python connector, cudf, ADBC) and array stream helpers (ADBC). I recently used the buffer-from-std-vector helpers for some GeoArrow tests also. > does strict minimalism apply to that as well or can the C++ layer grow more freely? There could definitely be C++ bindings to the C library (or standalone header-only C++ like sparrow)...I don't think that until now there has been anybody with interest in designing and maintaining the interface. C++17 is definitely the way to go here (but there would need to be discussion on the mailing list of whether this is a good idea since it's possibly stepping on Arrow C++'s/sparrow's toes and there would need to be significant interest in contributing/reviewing). > WRT using unit tests as documentation We definitely should have examples (the fact that we don't have them is just an issue of time) and the intention of the unit testing has never been to replace that. We are a C library, though, and the C library tests will need to have some C library calls in them and should vaguely follow our own advice (e.g., we advise C++ users to use the `nanoarrow::UniqueXXX` classes to manage cleanup). -- 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]
