Hello everyone!
I’m writing a new library where I need to be able to configure a struct. This
struct and its configuration will be accessed concurrently. One design pattern
I see throughout the standard library and community is to make the struct and
its configuration fields public but all other fields private.
e.g.
type MyServer struct {
ConfigureMe int
usedInternally string
}
This nicely complements Go’s default values and is very terse to use. This is
exactly how structs such as http.Server and autocert.Manager (part of the new
acme library) are used.
As aforementioned, the configuration fields in my struct need to be accessed
concurrently. My issue is that since the configuration fields are public, they
can be freely mutated by a package user and so a race condition may occur. I’m
not sure how big of an issue this is considering its very unlikely that someone
will mutate the struct once its being used but the design feels a bit fragile
to me.
In search of a better way, I thought about using a config struct but then I
found Dave Cheney’s post
https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis
<https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis> about
using functional options and now I’m thinking of using those. However, I
haven’t seen this API design used anywhere at all in any library I have ever
used (or in the standard library at all) so I was wondering whether or not it’s
idiomatic.
I’m not sure if I’m being overly pedantic in my criticism of having the
configuration fields public in the struct. I don’t have too many configuration
fields so maybe functional options will be overkill.
I’m not really sure what I should go with now and I’ve hit a mental block with
my design. I’m hoping someone will have some thoughts on what approach I should
go with.
Thanks!
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
