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.


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.

Reply via email to