I think this discussion shows complementary definitions of traits:
- verb-based traits: a type agrees to implement all the verbs
appropriate to the given "verb trait"
- noun-based traits: a type agrees to contain certain underlying data
(and thus the getter/setter verbs could be implicitly defined for those
fields)
Whatever the final implementation of traits in Julia, I think keeping in
mind this distinction could be helpful.
On Wed, Oct 21, 2015 at 12:42 PM, Stefan Karpinski <ste...@karpinski.org>
wrote:
> 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.
>
