On Mon, Mar 5, 2018 at 9:53 PM, Randall O'Reilly <rcoreil...@gmail.com> wrote:
> On Mar 5, 2018, at 10:32 PM, Ian Lance Taylor <i...@golang.org> wrote:
>>
>> 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
>
> So why then does reflect.TypeOf(obj) return the “Outer” type in the example
> code I posted, here:
>
> func ArgFun(in InType) {
> typ := reflect.TypeOf(in).Elem()
> fmt.Printf("ArgFun on in tells the truth: %v\n", typ.Name())
> }
>
> https://play.golang.org/p/KmihXxU19Dd
Because that isn't a call of a promoted method. That's examining the
dynamic type of an interface value.
> Per the discussion here: https://github.com/golang/go/issues/22013 — it seems
> like Go is rather unclear about exactly what level of C++-like inheritance it
> wants to support. I don’t want to recreate any of that discussion here, but
> I’ll just add a tiny vote for at least keeping the notion of embedding as it
> is — don’t throw the baby out with the bathwater! The presence of interfaces
> and the compositional model in Go is TONS better than C++’s rigid inheritance
> constraints, but sometimes a simple inherit-and-extend model is just the
> right thing, and it seems like it doesn’t add that much additional complexity
> to support it. Maybe just need to add a bit of relevant docs in places to
> resolve residual confusions, such as the one I encountered. Thanks for all
> your hard work on creating this awesome language!
I want to repeat that Go doesn't support any sort of C++-like
inheritance at all.
In C++, declaring one class as a child of another class (class child :
parent) is both a subtyping relationship and an inheritance
relationship. In Go those notions are separate. In Go embedded
fields provide an inheritance relationship: the child object--the one
with the embedded field--acquires the behavior of the parent object.
But Go's embedded fields are not a subtyping relationship: the child
object can not be used in place of the parent object, as it can in
C++. In Go, subtyping is expressed using interface types. A type
that implements an interface can be considered a subtype of that
interface--the implementing type can be used anywhere the interface
type can be used--although there is no inheritance relationship.
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.
