How are Interfaces Represented in Go?
Various resources describe the representation of interfaces in Go, but some may appear contradictory. This article aims to clarify the confusion by highlighting the differences in granularity between two such resources.
Understanding the Differences
The article titled "Laws of Reflection" focuses on the low-level details of how objects are examined using reflection. It explains that an interface value contains a pair, (value, type). For example, the variable r in the following code is described as having the pair (tty, *os.File):
<code class="go">var r io.Reader tty, err := os.OpenFile("/dev/tty", os.O_RDWR, 0) if err != nil { return nil, err } r = tty</code>
On the other hand, the second article examines the dynamic dispatch properties of interfaces. It explains that the runtime resolves interface methods based on an "itable" associated with the interface's implementation. For example, in the diagram for a Stringer interface holding a Binary type, the itable lists the methods used to satisfy the interface (String), but not additional methods implemented by the Binary type.
Reconciling the Differences
These two resources are discussing the same concept at different levels of abstraction. The first discusses the implementation of reflection, while the second focuses on runtime behavior.
At runtime, an interface acts as a "wrapper object" that provides information about the wrapped object to facilitate dynamic dispatch. This explains why calling Read on r in the first example works: it uses the itable to locate the Read function implementation in the *os.File type.
In summary, understand interfaces as runtime "wrapper objects" that provide information for dynamic dispatch. Reflection provides a higher-level representation of this as a (value, type) pair.
The above is the detailed content of How Do Interfaces Work in Go: Reflection vs. Runtime Behavior?. For more information, please follow other related articles on the PHP Chinese website!