HaloO,
Brad Bowman wrote:
Sam Vilain wrote:
This will be the same as requiring that a class implements a
method, except the method's name is infix:<==>(::T $self: T $other)
or some such.
Sure. The point is, how does a role designer mix in the x and y
coordinate attributes *and* augment the notion of equality to
encompass these new attributes *without* shifting this burden onto
the class implementor!
Does the "class GenSquare does GenEqual does GenPointMixin" line
imply an ordering of class composition? This would seem to be
required for the super.equal hand-wave to work but part of the Traits
Paper goodness came from avoiding an ordering. Composition is just
order insensitive flattening. Conflicts like the equal method in the
OP have to be explicitly resolved in the target class, either using
aliases or fully qualified names. So there's no super needed.
Hmm, my aim was more at the class composition process as such.
I envision a type bound calculation for all composed roles. This
bound then is available as super to all roles. Inter-role conflicts
are orthogonal to this. If the bound is fulfilled the order of
role composition doesn't matter. In the case of the equality checks
the different participants of the composition call each other and
use logical and to yield the final equality check. To the outside
world the equality method appears to be a single call on the type
of the objects created from the class. Note that it is type correct
in the sense that all participants are considered. My hope is that
this is achieved automatically as outcome of the composition process
and not by intervention of the class implementor.
(I should confess that I haven't yet read the OP linked article),
To understand it you might actually need to read previous articles
in the series, too.
Regards,
--
