On Tue, Oct 20, 2015 at 7:00 PM, Brendan Tracey <tracey.bren...@gmail.com>
wrote:
>
> > Above, a relatively simple macro can replace all the "Type..." with the
> fields of the composed types, applying multiple inheritance of the
> structures without the baggage required in classic OOP. Then you can
> compose your type from other types, but without having to write
> "unicycle.wheel.radius"... you can just write "unicycle.radius".
>
> 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.
>
I do like this approach to composition/delegation, but it requires
automatically adding a lot of methods to the delegator, i.e. Unicycle in
this example, from all of its components, which feels kind of nasty and
dangerous, especially since we allow dynamic addition of methods
after-the-fact. In other words, you might add a method to Wheel, Frame or
Seat at any time, which would presumably then also apply to Unicycle
objects, potentially with unexpected consequences. It would be nice if the
delegation was more limited than that. Go doesn't have this problem since
you can't dynamically add methods – everything is known at compile time.
