I'm glad this led back to opaque types. 8-D Using something like TitleField type is probably too much for the simple example, but a great solution for a site that has to be really robust! hecrj/composable-form looks great, I'm going to check that out too.
As for type aliases... I don't know enough about compiler design to have an informed opinion, but what I described is how I would "want" type aliases to work. I totally understand that after being compiled they're all just Strings (in this example), but if the coder specifies a different name I think I want a step somewhere that will catch that if the wrong name is used. But your TitleField solution is better anyway, it provides a lot more than just a new name for a type. 8-)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm glad this led back to opaque types. 8-D Using something like
TitleFieldtype is probably too much for the simple example, but a great solution for a site that has to be really robust!hecrj/composable-formlooks great, I'm going to check that out too.As for type aliases... I don't know enough about compiler design to have an informed opinion, but what I described is how I would "want" type aliases to work. I totally understand that after being compiled they're all just
Strings (in this example), but if the coder specifies a different name I think I want a step somewhere that will catch that if the wrong name is used. But yourTitleFieldsolution is better anyway, it provides a lot more than just a new name for a type. 8-)