danepitkin commented on issue #36864: URL: https://github.com/apache/arrow/issues/36864#issuecomment-1650014224
It would be nice to keep the the `readr` support for write APIs if its already done for the read APIs. However, is it possible to do this without introducing a breaking change? From the user's perspective, it would be great to have the current API supported, but marked deprecated, when the new API definition is introduced. Is there an easy way to do function overloading in R? If we have to have a single function definition with multiple parameter options for the different "versions" of the API, we should document which parameters are deprecated and let the non-deprecated equivalent options always take precedence. I'm not sure how complicated this code would be, but if it's manageable we can always delete the deprecated code in a later release. Long term, I'm not sure how valuable it is to tie our interfaces to another package's interfaces. This can be great for package adoption early on, but if the Arrow package is successful on its own it can be better for both the user and maintainer to have an interface optimized for the implementation. You'll sometimes see packages start with an interface that mimics another piece of software's interface, but once popular they implement their own. It all depends on what is the biggest hurdle for your users e.g. getting started vs usability. -- 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]
