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:
type UserRole string
type GroupRole string
const (
// I prefix the names of my consts with the name of the variable to avoid naming conflicts.
UserRoleGuest UserRole = "guest"
UserRoleContributor UserRole = "contributor"
UserRoleAdmin UserRole = "admin"
GroupRoleGuest GroupRole = "guest"
GroupRoleMember GroupRole = "member"
GroupRoleLeader GroupRole = "leader"
GroupRoleAdmin GroupRole = "admin"
)
type User struct {
Name string
Role UserRole
GroupRole GroupRole
}
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:
type UserRole string
type GroupRole string
const (
// I prefix the names of my consts with the name of the variable to avoid naming conflicts.
UserRoleGuest UserRole = "guest" // @name Guest
UserRoleContributor UserRole = "contributor" // @name Contributor
UserRoleAdmin UserRole = "admin" // @name Admin
GroupRoleGuest GroupRole = "guest" // @name Guest
GroupRoleMember GroupRole = "member" // @name Member
GroupRoleLeader GroupRole = "leader" // @name Leader
GroupRoleAdmin GroupRole = "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.
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.