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

consider Types as string rather than int. #50

Closed
smoser opened this issue Apr 1, 2020 · 2 comments
Closed

consider Types as string rather than int. #50

smoser opened this issue Apr 1, 2020 · 2 comments

Comments

@smoser
Copy link
Collaborator

smoser commented Apr 1, 2020

@tych0 brought up this question in #49.

In the initial design, @rchamarthy set up constants for "type identifiers" (LVType, DiskType, AttachmentType) using integer type and iota.

As I am (ab)using json as a output format, I then wrote marshallers and unmarshallers that display these types as strings and support reading them as integer or string.

@rchamarthy, could you give some reasoning for why we have:

type LVType int
const (
   THIN LVType = iota
   THICK
)

rather than:

type LVType string
const (
   THIN = LVType("THIN")
   THICK = LVType("THICK")
)
@rchamarthy
Copy link
Contributor

@smoser these to me are actually enums and i would like to use them as such in code. For example use them as index in an array etc. The go idiom is to go generate the boiler plate for making these types serializable to strings.

@smoser
Copy link
Collaborator Author

smoser commented Apr 6, 2020

@rchamarthy thanks. I did not know of go generate. Thats useful.

A few googles didn't show any hits for json usage we're doing, but thats fine. we definitely could use go generate for many of the strings. thanks.

@smoser smoser closed this as completed Apr 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants