Leveraging the Go Type System
gopherguides.com
Leveraging the Go Type System
1–10 of 112 posts
Re: Leveraging the Go Type System
#2You can also use `go generate` to generate the code that translates constants into strings.
Re: Leveraging the Go Type System
#3So what you are describing is enums but way more complicated?
Re: Leveraging the Go Type System
#4For an example with Go generation and using iota see stringer[0] and Rob Pike's related blog post[1]
Re: Leveraging the Go Type System
#5Semi related question: what resources do you recommend for go's state of the art regarding best practices, idiomatic project structure, tooling and the like? Preferably books, but I'll take anything.
I searched recently and most of what I saw were either in depth books about the language itself, outdated blog posts, or non-relevant books that just happened to use go to explore an unrelated topic.
Re: Leveraging the Go Type System
#6So what you are describing is enums but way more complicated?
In a way, yes. Go doesn't have the concept of enums, so this is as close as it gets.
Re: Leveraging the Go Type System
#7Semi related question: what resources do you recommend for go's state of the art regarding best practices, idiomatic project structure, tooling and the like? Preferably books, but I'll take anything. I searched recently and most of what I saw were either in depth books about the language itself, outdated blog posts, or non-relevant books that just happened to use go to explore an unrelated topic.
Well, we obviously have paid courses that cover all this, but if you want my personal opinion on package layout, Ben Johnson really has a great article on it here: https://www.gobeyond.dev/packages-as-layers/
Re: Leveraging the Go Type System
#8The points about iota are interesting. I always define the first constant as "unknown" when defining a set of iota-driven constants. That way the zero value is "unknown" so if I create a new struct with no initialiser it doesn't accidentally inherit a value I didn't mean it to have, and instead gets the "unknown" value.
It also doesn't touch on the other useful "system" funcs to include on a type (Scan, Value, Marshal, etc)
Re: Leveraging the Go Type System
#9I really like this example, because it highlights both the strengths and weaknesses of Go in the same example.
On the one hand: Good language support for a specialized type and a method on that type, without making the type a heavyweight class (i.e. all that magic can happen at compile-time; Genre can still be an int "under the hood").
On the other hand: wow, that's a lot of boilerplate to write just to get the string representation of a token the compiler already knows about. As other commenters have noted, `go generate` will decrease the amount of code that needs to be hand-written, but it still smells like something the language should handle without explicit code.
Re: Leveraging the Go Type System
#10The points about iota are interesting. I always define the first constant as "unknown" when defining a set of iota-driven constants. That way the zero value is "unknown" so if I create a new struct with no initialiser it doesn't accidentally inherit a value I didn't mean it to have, and instead gets the "unknown" value. It also doesn't touch on the other useful "system" funcs to include on a type (Scan, Value, Marsha…
Agreed. There are a couple of clever ways to handle iota, but as my next article suggests, in general, I steer away from them if you really just need constants.
I didn't go into any of the Scan/Value/Marshal etc as it was a little beyond the scope of this article. I can certainly do a follow up article on it though
Thanks for the feedback!