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.
I want to be able to generate enum variants whose names do not exactly match the name of the variable in the Go code. You can imagine a few different reasons to want to do this, but my reason can be shown by the following:
typeUserRolestringtypeGroupRolestringconst (
// I prefix the names of my consts with the name of the variable to avoid naming conflicts.UserRoleGuestUserRole="guest"UserRoleContributorUserRole="contributor"UserRoleAdminUserRole="admin"GroupRoleGuestGroupRole="guest"GroupRoleMemberGroupRole="member"GroupRoleLeaderGroupRole="leader"GroupRoleAdminGroupRole="admin"
)
typeUserstruct {
NamestringRoleUserRoleGroupRoleGroupRole
}
Currently, this will produce a type called UserRole with enum varnames UserRoleGuest, UserRoleContributor, UserRoleAdmin. When using this type from auto-generated code, it makes all the enums look like UserRole.UserRoleGuest. It's not too bad in this case but I've got some types called things like ProjectMembershipRole and having to type ProjectMembershipRole.ProjectMembershipRoleAdmin is a pain.
Describe the solution you'd like
In the same way that you can override the name of types, you should be able to override the name of constants, too.
Example:
typeUserRolestringtypeGroupRolestringconst (
// I prefix the names of my consts with the name of the variable to avoid naming conflicts.UserRoleGuestUserRole="guest"// @name GuestUserRoleContributorUserRole="contributor"// @name ContributorUserRoleAdminUserRole="admin"// @name AdminGroupRoleGuestGroupRole="guest"// @name GuestGroupRoleMemberGroupRole="member"// @name MemberGroupRoleLeaderGroupRole="leader"// @name LeaderGroupRoleAdminGroupRole="admin"// @name Admin
)
This does not cause any conflicts because the enum varnames are always scoped to the enum type.
Describe alternatives you've considered
You can specify varnames at the field like as documented in the README, but I'm using these types across many different structs and I don't want to have to add the varnames override for every single field.
Another option would be to use the constant's documentation instead of the line comments. This would be a valid way of doing it too, it's just more effort and more different from the way it works at the moment (currently Swag parses the line comments for the enum variant comment).
Additional context
I have a PR implementing this which I will link into this once it is up.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
I want to be able to generate enum variants whose names do not exactly match the name of the variable in the Go code. You can imagine a few different reasons to want to do this, but my reason can be shown by the following:
Currently, this will produce a type called
UserRole
with enum varnamesUserRoleGuest
,UserRoleContributor
,UserRoleAdmin
. When using this type from auto-generated code, it makes all the enums look likeUserRole.UserRoleGuest
. It's not too bad in this case but I've got some types called things likeProjectMembershipRole
and having to typeProjectMembershipRole.ProjectMembershipRoleAdmin
is a pain.Describe the solution you'd like
In the same way that you can override the name of types, you should be able to override the name of constants, too.
Example:
This does not cause any conflicts because the enum varnames are always scoped to the enum type.
Describe alternatives you've considered
You can specify varnames at the field like as documented in the README, but I'm using these types across many different structs and I don't want to have to add the varnames override for every single field.
Another option would be to use the constant's documentation instead of the line comments. This would be a valid way of doing it too, it's just more effort and more different from the way it works at the moment (currently Swag parses the line comments for the enum variant comment).
Additional context
I have a PR implementing this which I will link into this once it is up.
The text was updated successfully, but these errors were encountered: