Hacker News Reader

Comment by lanstin | Hacker News Reader

I think most Go people will put most anything that goes over the wire into some protocol description language like protobuf or even swagger. Inside your call stack I am not sure you need enums instead of constants. If you are either persisting or transmitting data then you want some formal description which will essentially get you enums as useful symbolic values.

View on HN

Lack of real enums is one of my biggest annoyances with Go. So so many times I've put the wrong enum value in because it's just an int and it matches another set of enums. I've taken to putting each set of enums into a separate file and separate folder just to help the compiler catch this. The project I'm working on now has about 25 separate enum files+folders. Gagh!

I made this playground: https://play.golang.org/p/S1Yh0Oq24q-

There are a ways to do unique enums with implicit repetition. Like this: I 0 1 2 II 101 102 103 III 201 202 203 IV 10 20 40 80

Yes and no. Most of the time my enums are well defined: ContactStatus, AwardLevel, JugeStatus, for example. I have not control over the names or values and all have a "Revoked" value. When they come in from an external system it's pretty easy to parse them and convert them to the wrong type if someone isn't paying close attention. Then they don't get caught for a week or so because the code compiles, runs, and appears to work correctly except for these occasional odd results.

Typedefing with iota should let the complier catch this, but it is an extra wonky step

Reply on news.ycombinator.com