How are interfaces represented in Go?

Question

I\'m reading through two articles right now and am a little confused.

This article - http://blog.golang.org/laws-of-reflection says

> var r io.Re         


        

Answer 1

Both are correct, r "holds" (tty, *os.File) and that is what the second article says. Note that Laws of Reflection is a bit more high-level and does not mention implementation details (which might change in each release) like discussed in the second article. The diagram of the second article read as follows: "s contains schematically (b, *Binary). s is of type Stringer, its data is a Binary with value 200 and s's itable contains one method String and the other methods of Binary (or *Binary) are not represented in the itable and thus not accessible for s.

Note that I think the actual implementation of interfaces in Go 1.4 is different from what the second article (Russ's?) states. "

Answer 2

The two articles are explaining a similar concept at two very different levels of granularity. As Volker said, "Laws of Reflection" is a basic overview of what is actually happening when you examine objects via reflection. Your second article is examining the dynamic dispatch properties of an interface (which, can be resolved via reflection as well) and how the runtime resolves them at runtime.

According to the second article, the variable r in the first extract should be (tty, io.Reader)

Given that understanding, think of an interface at runtime as a "wrapper object". It exists to provide information about another object (the itable from your second article) to know where to jump to in the wrapped objects layout (implementation may differ between versions .. but the principle is basically the same for most languages).

This is why calling Read on r works .. first it will check the itable and jump to the function that is laid out for the os.File type. If that was an interface .. you would be looking at another dereference and dispatch (which IIRC isn't applicable at all in Go).

RE: Reflection - you're getting an easily digestible representation of this, in the form of a (value, type) pair (via the reflect.ValueOf and reflect.TypeOf methods).