From: chromatic [mailto:[EMAIL PROTECTED]
> On Wed, 2004-01-07 at 00:43, Jonathan Lang wrote:
> > Maybe as an alternative to
> >
> > role Stringify {must stringify();}
> > sub print_it (Stringify $thingie) {print $thingie.stringify();}
> >
> > you might be able to say
> >
> > sub print_it ($thingie must stringify()) {print
> $thingie.stringify();}
> >
> > Hmm... there's a certain elegance to being able to specify one or two
> > requirements directly in a signature.
>
> I'm not sure that works so well in practice. You're explicitly asking
> for a method with a particular name when you're ought to be asking for a
> method with a particular meaning. That is, if you said:
>
> method threaten ( $thingie must bark() ) { ... }
>
> passing in a Tree object would work, when what you really want something
> that does Doggish things, like a Dog, an Actor in a dog costume, or a
> RobotDog.
Ahh, this is the classic Damian interpretation.
Yes, passing in a Tree would satisfy the requirement. That's the intention.
If we wanted to say that the requirement was for a Dog role, we'd say that.
Instead, we're being very generic, and saying that anything with a bark()
method is valid fodder for this.
For example,
sub bark_louder($it must bark()) {
System::Audio::set_volume(+5);
$it.bark;
System::Audio::set_volume(-5);
}
> Promoting role names to a position of typishness allows roles to express
> the semantics and context of method names that method names alone can't
> express uniquely.
>
> Yikes, now I sound like Larry.
Sure, but you're missing the point. It's not "methods instead of roles",
it's "methods when even roles are too abstract."
=Austin
