-
Notifications
You must be signed in to change notification settings - Fork 66
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
Sub-types naming conflicts #695
Comments
Yeah. Naming is hard. See #1. What I'd like to do is defer naming until after we've added all items to a "namespace". Then the namespace would be responsible for choosing names. Previously, I was of the opinion that we should try to use context and heuristics to choose good names. I'm increasingly of the opinion that we will want or need a mechanism that allows users to resolve name conflicts. Consider, for example, this schema we get from a GitHub OpenAPI document: {
"type": "string",
"enum": [
"+1",
"-1",
"laugh",
"confused",
"heart",
"hooray",
"rocket",
"eyes"
]
} How would we produce variant names for My current (background) focus is to have a more complete handling of references to external files and non- {
"type": "string",
"enum": [
"+1",
"-1",
"laugh",
"confused",
"heart",
"hooray",
"rocket",
"eyes"
],
"x-code-rename": {
"+1": "plusOne",
"-1": "minusOne"
}
} In your particular case, I'd love typify to identify the name conflict, produce a meaningful error:
|
The following definitions will result in both an Enum and a Struct named
AaBb
:We might need an alternative way to name types in types. Maybe
AaSubBb
orAaBbProp
, idk.The text was updated successfully, but these errors were encountered: