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

Naming Inline type definitions in generated code #64

Closed
desaikd opened this issue Nov 16, 2023 · 1 comment
Closed

Naming Inline type definitions in generated code #64

desaikd opened this issue Nov 16, 2023 · 1 comment
Assignees
Labels
code generation Improvements for code generation subcommand `generate`

Comments

@desaikd
Copy link
Contributor

desaikd commented Nov 16, 2023

There are few alternatives to consider for naming inlined type definitions in generated code.

🗺️ Template for Rust modules that declares all the modules generated based on given type definitions.This also includes inline type definitions(anonymous type definition) that doesn't have a name.(e.g. address: { type: string }) Naming for these types is based on a counter starting with AnonymousType1. I have selected this name to imply that these are type definitions that weren't named in schema file, but I am open to other suggestions for naming these types.
Some alternatives,

  • Name these types as InlinedType*.
    • Problem: If we use this approach which is similar to current implementation (AnonymousType*). Then there is a question of collision when user has the same name for a different type definition.
    • Solution: We can use a different module where all the generated inlined types live.
  • Make a code generation constraint as open content in schema that allows naming these types (e.g. address: { $codegen_type_name: address_string, type: string } )
    • Problem: Requires user to name all their inlined types.
    • Solution: We can combine this solution with above naming appraoch and make $codegen_type_name optional.

Originally posted by @desaikd in #61 (comment)

@desaikd desaikd added the code generation Improvements for code generation subcommand `generate` label Nov 16, 2023
@desaikd desaikd self-assigned this Feb 22, 2024
@desaikd
Copy link
Contributor Author

desaikd commented Apr 19, 2024

Closing this in favor of another issue that has more details on this: Related issue: #103

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code generation Improvements for code generation subcommand `generate`
Projects
Development

No branches or pull requests

1 participant