Larry Wall wrote:
I've been sloshing all this through my muddled head again, and I'm
beginning to see this as more of a naming policy issue, that is, an
authority issue. The problem with "done_by" is that you're modifying
something in place, which mixes up the one name to mean two different
things. But this sort of problem is almost exactly what the naming
authority was added for. Suppose JRANDOM's version of Num says:
role Num-1.3-JRANDOM does OUTER::Num does Complex;
method re (--> OUTER::Num) { self }
method im (--> OUTER::Num) { 0.0 }
...
Then if you say
use Num-1.3-JRANDOM;
then for the rest of your lexical scope, Num is known to do Complex,
without backediting of the standard Num role. The only "downside"
I can see is lack of Magical Action at a Distance--other lexical
scopes will also have to declare the Num alias, either directly or
via a policy module.
So if I'm understanding you correctly, what I'm looking for would be
something along the lines of:
Scenario: someone has created a module with a Num role, complete with
all the comparison operators needed to do ordering, etc.; but they
neglected to consider the possibility of factoring out the ordering
capabilities - that is, they failed to define a separate Order role
that Num composes. Due to Perl 6's nominative type system - i.e.,
_not_ duck-typing - I would not be able to simply create an Order role
with the appropriate methods and expect "sub sort(Order @list) {
sortit }" to be able to accept a list of Num. To get around this, I'd
like to insert "does Order" into the definition of Num:
# define a generic Order role
role Order {
method infix:<cmp> ($rhs) { doit }
...
}
#<create a specialized version of Num that composes Order, and
resolve the resulting conflicts between Order and the original version
of Num>
role Num-1.0-dataweaver does OUTER::Num does Order {
method infix:<cmp> ($rhs) { return OUTER::Num.cmp $_: $rhs }
...
}
...
use Num-1.0-dataweaver;
Outer::Num still won't be usable in the sort routine; but it will be
hidden by Num-1.0-dataweaver, which behaves identically to OUTER::Num
in all respects except that it _can_ be used in place of Order:
my Num @x; # Num refers to Num-1.0-dataweaver instead of OUTER::Num.
sort @x;
That's... doable. It seems like an awful lot of work just to expand
the types that an existing role will match; but at least it's
possible, after a fashion.
--
What I'd rather have would be something along the lines of:
role Num { ... }
...
role Order { ... }
...
Num.cando(Order);
The last line would be to .does() as the assignment operator is to the
equality operator, except that .cando() would fail unless Num can
already do all of Order's methods. I.e.: if (and only if) Num already
matches Order in terms of duck-typing, .cando (or whatever) would
legitimize the relationship in terms of the nominative type-checking,
such that 'Num.does(Order)' would thereafter be true.
--
Jonathan "Dataweaver" Lang
