On Fri, Sep 7, 2018 at 9:34 AM Eric Raymond <e...@thyrsus.com> wrote: > The attached program lists
For future reference, it would probably be easier for the mailing list to discuss example code via a link to the Go playground, especially for runnable code. In this case: https://play.golang.org/p/IripNZNYIgo > In the attached program, I would like to be able to remove the &x argument > from ListFields. That is, I want the Inner code to be able to reflect on the > Outer instance without having to be fed the address of the Outer instance > explicitly. I specifically do *not* want to move the method to Outer - > reflection from within Inner is the point of the exercise. The short answer is no, not possible. Embedding Inner is not inheritance. It is essentially sugar, as if you said type Outer struct { fieldName Inner id int } and for every method foo on Inner, there was an implicit forwarding method: func (o *Outer) foo(etc) { o.fieldName.foo(etc) } it's just that you don't have to explicitly type "fieldName", or those forwarding methods. But that's it. Unlike Java's "(almost) everything is an Object", a value's type is a compile time concept, not a runtime one (ignoring Go's interface types, for now). If you have an Inner, all you have is an Inner, and you can't distinguish "an Inner inside an Outer struct" or "an Inner inside an array of 10 Inners" or "an Inner inside a Bar struct inside a Qux struct". But also unlike Java, you can embed multiple concrete types (the embeddee also doesn't have to be the first field), just like a struct can have multiple fields: "type Outer struct { Inner0; Inner1; id int; Inner3; }". To repeat, embedding isn't inheritance. It's not that the Outer value is-a Inner, it's that it contains-a Inner. > Is there a way for a struct instance to get its own address through the > runtime? In "func (x *Inner) Etc(etc)", the address of the struct is the variable "x": https://play.golang.org/p/PP7LKDxEHrg But I don't think that's going to help you. You can't go from a pointer-to-Inner to a pointer-to-Outer without knowing (i.e. passing) the Outer type (assuming that there's more than one Outer type), and if you're passing the Outer type, you might as well pass the Outer pointer. > The application would be to walk through the user-defined methods of a > Cmd-like interpreter instance. Asking about embedding and reflection sounds like an XY problem (http://xyproblem.info/). Can you elaborate on what "walk through the user-defined methods of a Cmd-like interpreter instance" is? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
