7 ms·

Really? Interfaces everywhere you can possibly imagine? Is that where we're heading in Go land?

• carbocation 10y ago
  For libraries, accepting interfaces (not interface{} but a useful interface with expected methods) seems to be better than accepting a specific type. For 'main' programs, I don't find this to be true. Do you have concerns about interface arguments?
  • kornish 10y ago
    A rule of thumb I've heard and agree with for libraries is "accept interfaces, return structs". Rationale here: https://medium.com/@cep21/what-accept-interfaces-return-structs-means-in-go-2fe879e25ee8#.jg58ibigk https://medium.com/@cep21/what-accept-interfaces-return-stru....
    • clusmore 10y ago
      The linked article doesn't elaborate on the "return structs" part. Personally I prefer to return only the bare minimal functionality that your caller should expect, so that they don't depend on something they shouldn't and you don't break them when you change to give them less. What are the best reasons to return structs?
      • majewsky 10y ago
        This is also the style advocated by the standard library. See for example the helper functions for io.Reader: https://golang.org/pkg/io/#Reader https://golang.org/pkg/io/#Reader For example, `io.TeeReader` returns `io.Reader` (the interface). The underlying type that implements the tee functionality is left private because you don't need to be able to see it. It really drives home the point that the return value is "just another io.Reader".
      • junke 10y ago
        This depends on the purpose of your function. It is the responsibility of the caller to not assume too much about dependencies, but you should help by being clear about the expected types of your functions. However that doesn't mean you should restrict yourself to always returning interfaces. Imagine your documentation says: this functions returns a List of items. You can still returns a CopyOnWriteArrayList. Your only promise is that it will satisfy List, but if you returned the interface, you would remove the ability for the next developer, which has more information than you, to rely on it. Since you cannot know in advance who is going to use the return value, giving the most specific type is the approach that is the most composable. A private function that knows what to do with CopyOnWriteArrayList can rely on it. Other code that works on List can accept the value because it is a List. If your interface is going to be public, then relying on the documentation might not be enough, and then you are welcome to define facade functions which hide internals.
        • clusmore 10y ago
          >Imagine your documentation says: this functions returns a List of items. You can still returns a CopyOnWriteArrayList. I don't write in Go so I don't know how the Go community feels about this, but I don't like the idea of a mismatch between documentation and implementation. A non-trivial number of people will only read the documentation when something goes wrong. If the function is defined as returning a CopyOnWriteArrayList they will assume that's the return type. If they bother to read the documentation, the mismatch will be confusing and the more obvious inference will be that the documentation is simply out of date. >you would remove the ability for the next developer, which has more information than you, to rely on it Yes, this is exactly what I _want_ to do. If the fact that I produce a specialised type rather than an interface is purely incidental, then I don't _want_ people to rely on it -- I won't be able to change my mind later. "Don't promise what you can't deliver." If it's not incidental, then of course be as precise as you feel is appropriate. Also I'll concede that this opinion is mostly for library writing, less so for internal usage where the caller is you/your team anyway.
    • fiatjaf 10y ago
      My rule of thumb is: if you don't have a simple name for your interface and you're about to call it "<your-struct-name>Interface", then you shouldn't have an interface.
• spraak 10y ago
  If you mean for `interfacer`, I think that the example there is too arbitrary, or at least I'd hope that the real world usage of this would be to analyze many thousand lines of a package or something..
• paulddraper 10y ago
  He he. Soon people will collaborate on a Go EE (enterprise edition) standard, and Go will introduce optional generics and later, lambda syntax.
  • mappu 10y ago
    > Soon people will collaborate on a Go EE (enterprise edition) standard Yeah - build your application as a Caddy plugin, then you can use their routing / ACME handling... There are a lot of similarities. Hopefully Go developers can bypass some of the pitfalls along the journey.
  • smnplk 10y ago
    Duke Gopher
• twblalock 10y ago
  > Really? Interfaces everywhere you can possibly imagine? Is that where we're heading in Go land? That should be where you are heading, because contracts should be separated from implementation, things should not be tightly coupled, etc. This is good programming practice. How can you be opposed to accepting interfaces instead of implementations, especially in a standard library or the standard tooling for the language?
  • theparanoid 10y ago
    Reading interface heavy code is harder because interfaces are another layer of abstraction
  • deleted 10y ago
    [deleted]
  • fiatjaf 10y ago
    https://github.com/simeji/jid/blob/97c7f902bc210d7b0ebd3eaddabb8ecc62056bbc/query.go#L8-L30 https://github.com/simeji/jid/blob/97c7f902bc210d7b0ebd3eadd...
    • pkroll 10y ago
      That's not an interface everywhere you can imagine, that's a huge, bulky interface that should probably be many smaller interfaces. No one is arguing for 16-method interfaces when all you want to do is call s.Alert().
    • norswap 10y ago
      Your point?
  • sirclueless 10y ago
    Accepting interfaces is an implicit commitment to support external implementations of the interface. You can't add a method to an interface without breaking clients who do this. This makes interfaces more fragile than structs. A concrete example: If I have a NewFoo function that returns a Foo and a FooTaker function that accepts a FooInterface, I can't assume that new features I add in NewFoo are usable from FooTaker. If FooTaker just took a Foo, there would be no problems. This is, I think, the best rule of thumb for when to use an interface: If you expect consumers of your library to write their own data types that could be used by your library, define an interface they can satisfy. Otherwise just produce and consume a struct you control -- it will be much more flexible and maintainable in the long run.
• _ph_ 10y ago
  I don't think this tool is meant to enforce "interfaces everywhere", but rather a tool to give you insights into your code. If a functions parameter type could be changed into an interface instead of a concrete type, you could decouple it from that type. This is nice for library functions which then could be called with types defined by the client, as long as these types implement that interface.
• smnplk 10y ago
  Looks like Go is becoming java ;)
  • elcct 10y ago
    Well, some indeed try to sneak in what they learnt using Java into Go...