marioloko commented on issue #2988: URL: https://github.com/apache/arrow-rs/issues/2988#issuecomment-1301468253
I chose to create the `CodecOptions` thinking about future extensions of this configurations. I mean, right know the only configurable method of `CodecOptions` is `backward_compatible_lz4`, and so it has a builder with `no_backward_compatible_lz4` method. `ReadOptions`, `SerializedRowGroupReaderOptionsBuilder` and `SerializedPageReaderOptionsBuilder` has a `with_codec_options` which read those options. Therefore, If we add a new field to `CodecOption` in the future the interface of these structs will remain the same, the only struct that will change is the one of `CodecOption`, which will have a method `set_new_field`. However, it is possible to hide the class `CodecOptions` and make it private to the crate, which from an user point of view it probably makes sense, as the user does not care if the option `no_backward_compatible_lz4` is for the codec or for any other part of the application. But from a developer perspective, this approach will imply that if in the future we add a new option to `CodecOption`, as this struct is private to the crate, then we will need to implement the method `set_new_field` will have to be implemented in all the structs that hide `CodecOptions`, that is `ReadOptions`, `SerializedRowGroupReaderOptionsBuilder` and `SerializedPageReaderOptionsBuilder`. So in my opinions both options are valid, and it is just a design choice: - Making `CodecOptions` public will probably make less painful to add new options in the future. Maybe no other option is required, so maybe it is ok. Moreover, it hides the internals to the user. - Making `CodecOptions` private will make easier to add new options in the future, but we are exposing the internals to users, which usually is not desirable. Anyway, from `compression` module, only this struct will be public and the others will remain experimental. -- 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]
