On Friday, October 23, 2015 at 7:22:28 AM UTC-6, Abe Schneider wrote:
>
> Ah, okay, that is different then. What's the advantage of creating a new
> method versus copying the fields? I would imagine there is a penalty with
> each deference you have to follow in order to make that work.
>
The advantage is simplicity. A unicycle is a Frame, a Seat, and a Wheel, no
more, no less (unless we added more to the definition of course).
Inheritance gets complicated fast in C++ (again, can't speak for Scala)
with virtual functions, virtual vs. nonvirtual descructors. Additionally,
Unicycle doesn't inherit from anything. It's not a subclass of anything. It
can be used however.
As to dereferencing, types in Go are not boxed like in Java (for example).
We could construct Unicycle as
type Unicycle struct {
Frame
Seat
Wheel
}
or as
type Unicycle struct {
*Frame
*Seat
*Wheel
}
or any combination you'd like. In the latter case they are pointers, and in
the former they are not. So, first of all you can avoid the dereferencing
by not having pointers. Secondly, in Go all of the types are known at
compile type, so I believe you can call the function without going through
extra deferencing, even in the case where they are pointers.
