memory - How are interfaces represented in Go? -
i'm reading through 2 articles right , little confused.
this article - http://blog.golang.org/laws-of-reflection says
> var r io.reader tty, err := os.openfile("/dev/tty", os.o_rdwr, 0) if err != nil { return nil, err } r = tty
r contains, schematically, (value, type) pair, (tty, *os.file). notice type *os.file implements methods other read; though interface value provides access read method, value inside carries type information value.
this other article, says
in terms of our example, itable stringer holding type binary lists methods used satisfy stringer, string: binary's other methods (get) make no appearance in itable.
it feels these 2 in opposition. according second article, variable r in first extract should (tty, io.reader), static type of r. instead, article says *os.file type of tty. if second example right, diagram in first example should have of methods implemented binary type.
where going wrong?
the 2 articles explaining similar concept @ 2 different levels of granularity. volker said, "laws of reflection" basic overview of happening when examine objects via reflection. second article examining dynamic dispatch properties of interface (which, can resolved via reflection well) , how runtime resolves them at runtime.
according second article, variable r in first extract should (tty, io.reader)
given understanding, think of interface @ runtime "wrapper object". exists provide information object (the itable
second article) know jump in wrapped objects layout (implementation may differ between versions .. principle same languages).
this why calling read
on r
works .. first check itable
, jump function laid out os.file
type. if interface .. looking @ dereference , dispatch (which iirc isn't applicable @ in go).
re: reflection - you're getting digestible representation of this, in form of (value, type)
pair (via reflect.valueof
, reflect.typeof
methods).
Comments
Post a Comment