Interfaces in Go make it hard to navigate code

Re:Interfaces in Go make it hard to navigate code by DanWaterworth on Monday May 27, 2013 @04:50AM (#5773937)

I agree with the OP. The root of the problem, as I see it, is that you can't state in the documentation which interfaces a data type implements, because the interfaces may be declared outside of the "field of view". I think Haskell's solution to this problem is particularly elegant.

[ Parent | on HN ]

Re:Interfaces in Go make it hard to navigate code by dsymonds on Monday May 27, 2013 @07:08AM (#5774199)

You can state in documentation what interfaces a type implements. It is not uncommon to do that. For instance, the os package could have written something like:

  // File represents an open file.
  // It implements the io.Reader, io.Writer and io.Closer interfaces.
  type File struct {
    ...
  }

[ Parent | on HN ]

Re:Interfaces in Go make it hard to navigate code by DanWaterworth on Monday May 27, 2013 @08:22AM (#5774378)

Relying on people to do things consistently is not a good strategy. I'm sitting in front of a machine that I'd like to do that for me. Having to document this information manually is a disadvantage of Go when compared to other languages.

[ Parent | on HN ]

Re:Interfaces in Go make it hard to navigate code by MetaCosm on Monday May 27, 2013 @01:16PM (#5775487)

If I make a new interface that is an mix of io.Reader, io.Writer and io.Closer and I call this interface YouDidNotSeeMeComing -- then the file struct would also implement it... without even knowing it!

[ Parent | on HN ]