I think this is generally in-line with what I've been advocating for, and
not that different from Scala's mix-ins:
trait Wheel {
// ...
}
trait Frame {
// ...
}
class Unicycle extends trait Wheel, Frame {
// ...
}
is essentially doing the same thing (i.e. copying the member variables and
methods over).
As Stefan mentioned, Go is not traditional OO. This "composition-based"
> approach is part of Go's OO approach. In go, a type can have named fields
> of different types (like most OO languages), but also has "embedding". For
> example, if one declared
>
> type Unicycle struct {
> Wheel
> Frame
> Seat
> }
>
> then you could access the individual fields directly. So, if "u' is of
> type Unicycle, then you could access/set u.Cushiness directly. Similarly,
> if the embedded types had methods, i.e. frame.Color(), they can be called
> directly through unicycle, u.Color(). This is similar to, but distinct
> from, inheritance (the difference is that the Unicycle type doesn't
> actually have these fields, just the ability to call them easily, which is
> significant because of interfaces). In the case of clashes, the program
> must specify which is meant, so if both Seat and Frame had a Color()
> method, the user would have to specify u.Frame.Color vs. u.Seat.Color. In
> Go, this is handled by the compiler, and would need to be handled somewhere
> in the Julia runtime/REPL. It's a very nice paradigm, but would have to be
> made to fit within the broader Julia context.
>
>
>
>
