develooper Front page | perl.perl6.language | Postings from January 2004

Re: Roles and Mix-ins?

Thread Previous | Thread Next
Jonathan Lang
January 6, 2004 19:18
Re: Roles and Mix-ins?
Message ID:
Joe Gottman wrote:
>    How about something like
>         class Trog
>        does Dog {bark=>dogBark} does Tree {bark=>treeBark}
>        {...}
>     Then we could have code like
>       my Trog $foo =;
>       my Dog $spot :=  $foo;
>       my Tree $willow := $foo;
>       $spot.bark(); # calls dogBark()
>       $willow.bark(); #calls treeBark()
>    This works better when Dog::bark and Tree::bark are both needed but
> they do different things.

I'm not sure about the syntax, but it does a great job of illustrating the
aliasing approach to disambiguation.  The exclusion approach might be
something like: 

        class Trog
       does Dog 
       does Tree but no bark

so that, as far as class Trog is concerned, there I<is> no bark method for

That is, include a pair of traits[1]: "no" and "alias", where "no"
modifies the class to remove the specified attributes and/or methods, and
where "alias" modifies the class to rename the specified attribute or
method; then apply those traits to the roles in question as if they were
properties[2], creating singleton roles that are used to compose the
class.  This would require "but" to have a higher precedence than "is" or
"does", but I think that that might actually make sense.  

The only drawback to this is that I don't see the "no" and "alias" traits
being useful except as properties: you exclude a method from a class
simply by not defining it in the first place; and if you want to use a
different name for a given method, you simply use the different name for
it.  Then again, you could probably use "no" to implement something akin
to C++'s "private", where the method excluded by "no" is merely excluded
from use outside the class, while other class methods could see and use it
normally.  I suppose that a similar line of reasoning would technically
apply to alias; but it's beyond my ability to see how forcing a method to
be known by a different name by non-class methods than it is by class
methods could possibly be useful.  

Meanwhile, Luke was essentially pointing out that class methods take
precedence over role methods, and role methods I<can> be accessed by
explicitly specifying which role to use; so specifying a class method with
the same name as ambiguous role methods but which explicitly calls one of
them would also remove the ambiguity.  

[1] by "trait", I'm referring to a thing (which might or might not be like
a role but probably isn't) which is applied to a class via C<is> and which
modifies the standard rules for how the class behaves.  The more I look at
traits, the more I'm seeing them as being more sub-like than role-like:
they're defined more in terms of what they do to the class than what they
provide to the class.  

[2] by "property", I'm referring to a role that is applied to a class via
C<but>, resulting in a new singleton class that C<is> the original class
and C<does> the new role.  This differs from previous (and currently
official) use of the term in that I do I<not> assume that the role in
question has exactly one attribute.  If someone can come up with a better
term for "something like an official property, but more general", I'd be
more than happy to adopt its use instead.  

Jonathan "Dataweaver" Lang

Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About