You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
After using the bindings a bit, I've noticed that we currently have a mix of CPlusPlusLike identifiers and nix_c_api_identifiers for types.
Maybe the rule is that types with a direct C++ equivalent reuse that name? Even then it's probably not consistent now, and too arbitrary, as the C++ code can change over time.
My apologies if this has already been discussed.
Describe the solution you'd like
Switch to snake case for all types? E.g. nix_eval_state, nix_store_path, ...
We could add deprecated typedefs to help the existing bindings switch without breaking them.
Describe alternatives you've considered
Leave as is -> confusing
Change to CamelCase like the C++ code -> iirc we decided against this, so that it's obvious which API is used
I also think it makes sense to switch to snake_case.
I'm happy to open a PR for these changes if we agree on it. But I don't think we need to add deprecated typedefs if we do the change soon. Currently, we almost don't have any bindings, and we are introducing other breaking changes anyway.
roberth
added a commit
to hercules-ci/nix
that referenced
this issue
Jun 13, 2024
Is your feature request related to a problem? Please describe.
After using the bindings a bit, I've noticed that we currently have a mix of
CPlusPlusLike
identifiers andnix_c_api_identifiers
for types.Maybe the rule is that types with a direct C++ equivalent reuse that name? Even then it's probably not consistent now, and too arbitrary, as the C++ code can change over time.
My apologies if this has already been discussed.
Describe the solution you'd like
Switch to snake case for all types? E.g.
nix_eval_state
,nix_store_path
, ...We could add deprecated typedefs to help the existing bindings switch without breaking them.
Describe alternatives you've considered
Leave as is -> confusing
Change to CamelCase like the C++ code -> iirc we decided against this, so that it's obvious which API is used
Additional context
Priorities
Add 👍 to issues you find important.
The text was updated successfully, but these errors were encountered: