"All known implementing structs" of an interface?

[Kai Noda]

Hi all,

Background:
I'm a newbie with 0.5 days of Go experience.  Google search told me that bufio.Scanner was nice for looping over text lines, so I had a look at this page http://golang.org/pkg/bufio/#NewScanner

func NewScanner(r io.Reader) *Scanner

The signature tells me I should pass an instance of the io.Reader interface.  However, since Go adapts structural (rather than nominal) typing for its interfaces, I was at first perplexed about finding concrete types satisfying the interface.  (Now I know os.File is one of them.)

On the other hand, Javadoc has "All known implementing classes" section for a given interface, which I often find useful.  See, eg. http://docs.oracle.com/javase/7/docs/api/java/nio/channels/Channel.html

All Known Implementing Classes:

  AbstractInterruptibleChannel, AbstractSelectableChannel, AsynchronousFileChannel, AsynchronousServerSocketChannel, AsynchronousSocketChannel, DatagramChannel, FileChannel, Pipe.SinkChannel, Pipe.SourceChannel, SelectableChannel, ServerSocketChannel, SocketChannel

Question:
Are there anything like this in the Go world, at least for the standard libraries?

Best regards,
Kai

[Martin Schnabel]

On 12/19/2013 01:35 PM, Kai Noda wrote:
> All Known Implementing Classes:

> Question:
> Are there anything like this in the Go world, at least for the standard
> libraries?

there are two tools i know of that can be used to discover this
relationship:

oracle which has limited support to find interfaces and their
implementations in one package:

http://godoc.org/code.google.com/p/go.tools/cmd/oracle

and implements which finds interfaces and implementations in a number of
differing packages:

https://github.com/dominikh/implements

[Chris Hines]

sourcegraph.com

https://sourcegraph.com/code.google.com/p/go/symbols/go/code.google.com/p/go/src/pkg/io/Reader:type

[Kai Noda]

Hi Martin and Chris,

Thank you so much for your valuable information.  I'll give them a try (after installation of Go1.2 --- oracle and implements didn't compile with Go1.0 SDK from Ubuntu 12.04).  sourcegraph.com seems to be very useful for other purposes, too.

Kai

2013年12月19日木曜日 22時36分07秒 UTC+8 Chris Hines:

[Jsor]

Do remember that just because it satisfies an interface doesn't mean it... satisfies an interface. Interfaces are more than method signatures, they're about expected behavior. It's perfectly possible to satisfy some random package's Deleter { func Delete() } interface and yet if you were to actually let that package call said delete method, Bad Nonsense™ would happen. I could see my Graph implementations in Gonum technically implement some other package's Graph interface and yet not actually follow them the way they're intended to be followed.

[freder...@gmail.com]

On Thursday, December 19, 2013 2:18:47 PM UTC+1, mb0 wrote:

oracle which has limited support to find interfaces and their implementations in one package

The oracle extended the "implements" scope just a couple of days ago:

http://code.google.com/p/go/source/detail?r=e22a9223d6a96d05303004abd3859b498428c2b6&repo=tools

"implements: now shows whole-program implements relation for selected type.

(Previously it showed the implements relation for all types within the query package.)"

[Martin Schnabel]

thanks for the info. thats great and one more reason to use oracle!

[Kevin Gillette]

On Thursday, December 19, 2013 5:35:31 AM UTC-7, Kai Noda wrote:

"All known implementing structs"

It's easy to mistake structs as Go's version of a class (even if you aren't thinking about it in those terms), since both classes in other languages and structs in Go have members with visibility rules.  However, structs aren't special in Go, and don't "do" anything (methods are about behaviors) that any other kind of type can't do equally well; any named type (even something derived from an int, for example) can have methods, and any type can be the basis for a named type. In Go, there's no equivalent to the distinction other languages make between a class and a primitive, since all Go types consistently have the same properties related to (Go's flavor of) object orientation. Also, there's no abstract 'object' type (no super-base-type) in Go -- we really don't care much about hierarchies, so we don't have them.

P.S., while embedding may seem special, and out of the concrete type kinds is limited to just structs, it doesn't make structs special or class-like. The struct type kind wasn't created to support embedding (the concept of a struct is already useful on its own), but rather, embedding is simply a natural consequence of the properties of structs (which [can] contain multiple heterogeneous fields) and interfaces (which [can] contain multiple heterogeneous method signatures).

On Thursday, December 19, 2013 8:27:24 AM UTC-7, Jsor wrote:

Do remember that just because it satisfies an interface doesn't mean it... satisfies an interface.

True, but we need a different term for that. To be precise, any successful assignment of any value x to a given interface T means that, as far as the language and runtime are concerned, x implements T. What goes beyond the strict concept of interface implementation is the concept of semantics, which can be partially addressed with use of named types (if you provide the type and the interface, it's unlikely that someone will define an implementing type according to the wrong semantics).