On 2009-Oct-20, at 7:55 am, Matthew Walton wrote:
On Tue, Oct 20, 2009 at 2:32 PM, Mark J. Reed <markjr...@gmail.com>
wrote:
On Mon, Oct 19, 2009 at 11:47 PM, Jon Lang <datawea...@gmail.com>
wrote:
Because a method is part of a role, and ought to abide by the same
terms by which the role abides. If Logging doesn't do Numeric, it
shouldn't have any methods in it that won't work unless it does.
100% agreed.
So what the OP wants to do is declare a method that is available on
all those invocants - and only those invocatnts - which do all of
roles X, Y, and Z. Granted, you can declare a new role XandYandZ
that does X, Y, and Z, and define the method there, but that won't
work on $foo unless you declare explicitly '$foo does
XandYandZ' . The goal is to have the method show up no matter how
$foo comes to do all three roles.
Right.
This is an interesting idea. Currently, it doesn't work because
there's no place for such a method to live, so perhaps there could
be a way to declare a "method space" for arbitrary combinations of
roles, a sort of meta-role. It's an odd duck, but it does sort of
fall out of the multiple-dispatch semantics, which already let you
base implementation chioce on arbitrary combinations of roles...
Yes, and while the answer could always be "don't do that", the concept
doesn't seem particularly strange or undesirable. Maybe rather than
hide a "Numeric" method inside a "Logging" role where people wouldn't
expect to find it, we could do it this way:
role Numeric Logging { method log {...} }
or something alone those lines.
Well, if you could put a where clause on your invocant you could do
that...
method m($invocant where { $_ ~~ X and $_ ~~ Y and $_ ~~ Z }:
Int $a, Int $b) { ... }
I would expect "$foo where {$_ ~~ X}" and "X $foo" simply to be
different ways of writing the same thing, but whatever works!
-David
