Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why json.key for records but json.name for variants? #43

Open
jchavarri opened this issue Dec 3, 2024 · 3 comments
Open

Why json.key for records but json.name for variants? #43

jchavarri opened this issue Dec 3, 2024 · 3 comments

Comments

@jchavarri
Copy link
Member

Confused about this choice. There are already quite a lot of PPX attributes, and this case uses different names for different types for the same functionality. Could they both be called json.name?

Or to reduce cognitive impedance even more, use json.as which is very similar to mel.as.

@andreypopp
Copy link
Collaborator

this was done to align with ppx_yojson_conv and ppx_jsonschema_deriving

@jchavarri
Copy link
Member Author

But they still require to remember two attributes for the same thing. Besides, they are named name and key, not json.name and json.key. So no reuse is possible (if I want to use both melange-json and one of these ppxs, i'd need to add [@name "foo"][@json.name "foo"]).

Would you be open to support json.as in addition to the existing fields?

@andreypopp
Copy link
Collaborator

They can specify attributes without the namespace, e.g. @key will work both with json (both of them) and jsonschema deriving plugins.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants