Lars, 100% agree with your rationale; my question is an edge case of it.
The only need for these interfaces is for mocking the struct on tests (as shown in the link on my original post). Therefore, there is no other implementation of the interface. Your suggestion is close to our discussed option (3), except for the fact that in our discussion the "added word" to the name serves no functional differentiation purpose other than resolving the name conflict, although it "doesn't hurt" to provide more information about the struct. It would be like naming it "netPipe" when there is no "memPipe". On Sunday, 5 March 2017 13:24:15 UTC+13, Lars Seipel wrote: > > On Sat, Mar 04, 2017 at 03:57:48PM -0800, mlg wrote: > > according to your rationale, I believe the case I'm referring to is when > > the interface represents a domain object (e.g. Consumer). In such case, > if > > you don't plan on exporting your interface (therefore naming it > > `consumer`), how would you name the implementing struct and why? If > > possible, define a general rule. That's my question. Sorry if I wasn't > > clear before. > > Well, what is the defining characteristic that makes this type different > from other implementations of the same interface? That's how you should > approach the naming. > > Example: you're dealing with some kind of data-shoveling pipe (interface > name: pipe). The networked variant is called netPipe while you use > memPipe for the in-memory version used in testing. > -- 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.
