Is your feature request related to a problem? Please describe.
The current C API requires new set/get method pair for each new config options.
I'd like to reduce the number of new APIs required for new features.
Describe the solution you'd like
PEP 741 is a draft proposal for configuring embedded CPython interpreter.
Similar to Chewing there's a lot of configuration options. We can follow the API style proposed in PEP 741 to implement an extensible API that does not require new methods for new options.
Describe alternatives you've considered
libchewing used to have configuration object based API, however adding new features break ABI compatibility.
In Rust version we may continue to use configuration object approach, because adding a new field to #[non_exhaustive] struct is not a breaking change. But we may also use the same configuration method in Rust to make implementation easier.
Is your feature request related to a problem? Please describe.
The current C API requires new set/get method pair for each new config options. I'd like to reduce the number of new APIs required for new features.
Describe the solution you'd like
PEP 741 is a draft proposal for configuring embedded CPython interpreter.
Similar to Chewing there's a lot of configuration options. We can follow the API style proposed in PEP 741 to implement an extensible API that does not require new methods for new options.
Describe alternatives you've considered
libchewing used to have configuration object based API, however adding new features break ABI compatibility.
In Rust version we may continue to use configuration object approach, because adding a new field to
#[non_exhaustive]struct is not a breaking change. But we may also use the same configuration method in Rust to make implementation easier.