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

Reply via email to