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 = Trog.new();
> 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
Tree.
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
http://hotjobs.sweepstakes.yahoo.com/signingbonus
