On Tue, 2005-04-26 at 09:58, Abhijit Mahabal wrote:
> On Tue, 26 Apr 2005, Aaron Sherman wrote:
>
> > It also might be useful for roles to be able to delete members and
> > methods from a class like so:
> >
> > role foo {
> > has $.x;
> > has not $.y;
> > }
>
> But that brings up the issue of who has the final authority. In class
> composition, a method defined in the class hides those in the roles, and
> in this sense it is the boss on "adding decisions".
Quoting S12:
A class's method definition hides any role definition of the
same name, so role methods are second-class citizens. On the
other hand, role methods are still part of the class itself, so
they hide any methods inherited from other classes, which makes
ordinary inherited methods third-class citizens, as it were.
So in the case of class construction:
class x is y does z {...}
you should get x's methods plus any new ones from z plus any new ones
from y.
In the case of a mixin, I THINK the actual type of the new value is an
anonymous class, so it's something like this:
my $x = $y but z;
is
my (class {is ::{$y};does z;} $x = $y.clone;
or whatever the copy syntax is (and I might be wrong about how to
specify the type of $y... is there a typeof()?)
So, as you can see, in the case of mixins, the hypothetical:
role z {
has not mymeth;
}
would, in fact, remove mymeth from $x, and in class composition, it
would remove the method from parents, but not from the class being
declared (as it should not, by my way of thinking).
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
