On Mon, Mar 5, 2018 at 8:08 PM, Randall O'Reilly <rcoreil...@gmail.com> wrote: > Thank you for that clarification of what is happening under the hood. > > Nevertheless, I do think there are many cases where it would be very valuable > to have access through reflect of the true underlying type of the receiver > struct. This is evident in that stack overflow question, the *JSON code, and > probably many other cases where reflect is used. Just to be clear, in the > [Un]MarshalJSON code, the inability to access the true type means that you > cannot use an embedded interface to properly serialize derived types — any > generic functionality you might want to add to the process must be added > explicitly to each instance separately. This leads to a need for major code > replication, seemingly in contradiction to the Go philosophy. Furthermore, I > have many use-cases of wanting to generically access fields (Get / Set > values, etc) that might be on a derived type of my tree Node type. > > Anyway, if it is not technically possible, then there’s no point in wishing > for it. But I don’t think it is accurate to say that this would not extend > the power and elegance of the language. > > Meanwhile, in case others encounter this same situation, I have had to add a > “this” member to my Node struct that stores the interface pointer version of > the struct, so it is always possible to use that when access to the derived > type is necessary. Might make some Go folks barf, but it does the trick! > Just trying to get stuff working with the fewest LOC possible :)
Go doesn't have anything like inheritance in C++. What you are calling the "true underlying type" simply doesn't exist in Go. Go has embedded fields, and methods of embedded fields are promoted to become methods of the outer type in which they are embedded. But the outer type does not inherit anything from the inner type, at least not if you are using the word "inherit" in the sense that it is used in C++. The promoted methods are still methods on the inner type, they are just accessible directly from the outer type. I think it's generally best to approach these problems in terms of how Go works, rather than trying to recreate C++ approaches in Go. Go doesn't work the way that C++ does. Ian -- 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.
