Thank you both for your responses.
I’m going to switch to returning structs that implement an unexported interface. I don’t have a super convincing justification, but here are the reasons… 1: It’s unexported because it’s not expected to be implemented externally and passed in. But if a caller wants to implement their own (and still use Must <https://github.com/realclientip/realclientip-go/blob/f72b2beafd60ac4a2a07a943f47795760c105688/realclientip.go#L26> or ChainStategies <https://github.com/realclientip/realclientip-go/blob/f72b2beafd60ac4a2a07a943f47795760c105688/realclientip.go#L39>, for example), then they can define the interface themselves — I’ll have comment indicating this. (This unexported interface thing is used by pkg/errors <https://github.com/pkg/errors/blob/614d223910a179a466c1767a985424175c39b465/errors.go#L32-L39> and I’ve read reference to it elsewhere, but I can’t find where now.) 2: Why I’m concerned with implementing a particular interface or function signature at all, when I could just return any old thing: I would like to think that some users of the library would make the strategy a runtime decision based on configuration. So it would be nice if their code paths don’t care which strategy it is. 3: If the caller wants just a function, they can easily get with a bound method. Something like: getClientIP := realclientip.NewSingleIPHeaderStrategy("X-Real-IP").ClientIP Not lovely, but it works the same. 4: As Martin said, an interface means I could “potentially add other methods to it in future without breaking compatibility”. Now, I really, specifically want this to be very simple, slim library (I really do want it to be reimplemented in other languages), but I can imagine, say, collecting stats on calls and failures (empty string returns). Then adding a String() method that prints those stats and/or the strategy type and configuration (I like logging such things). (Yes, the library user could also just add a wrapper that does that.) I haven’t start making the changes yet, so it could all feel like garbage — we’ll see. I’m also not yet settled on the names of things — I’ll pay more attention to the verb-iness/noun-iness. Thanks again. Adam -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/c83a2c98-f11d-4341-9fcf-d0b35d59ad06n%40googlegroups.com.
