On 2009-Oct-18, at 3:44 pm, Jon Lang wrote:
David Green wrote:
I would expect that   role Logging { method log(Numeric $x:) {...} }
means the invocant is really of type Numeric & Logging, without Logging having to do Numeric. On the other hand, I can see that strictly that might not make sense, so perhaps I really do need to create a compound NumLog type first, so I can have method log(NumLog:)?
I think you should need to do this.

That's cumbersome, though. I don't want to create some new type, that happens to do Numeric and Logging (in addition to other stuff it might do); I want to affect everything else that does both roles. That is, I don't want my special log() method to work only for other types that explicitly do NumLog; I want it to work for any type that directly "does Numeric does Logging".

In fact, I can already refer to that combination without needing to create a compound type; for example, in a signature I can say "(Numeric Logging $x:)". I want my log() method to apply to $x there, even though it's "Numeric Logging" and not "NumLog".

I don't like dangling methods outside of any role though, either. What I want to be able to do is say:
    role Logging { method log(Numeric $x:) {...} }

and have it treat the invocant as something that does Logging (naturally, since it's part of the Logging role), and that also does Numeric (as specified in the sig). It's too reasonable a thing to do not to have a reasonable way to express it.

Of course, I could do something like this:
    role Logging
        method log
            given self
                when Numeric {...}
                when Stringy {...}

that is, I can do the "dispatching" myself. But I shouldn't have to, especially in cases that are more complex than this simple example.

(But I'll suggest something new for -> in general: what if "$x -> Numeric" with no "$n" variable were shorthand for "$x -> Numeric $x is rw", i.e. a shorthand that used the same variable name inside the block as the one being passed in? That would be useful in cases like this where we don't particularly want to rename $x.)

It wouldn't always be workable; for instance, "@a -> Numeric, Stringy { ... } would grab the first two element of @a and would put them into parameters; but there would be no obvious names to assign to those

Yes, and I think it's OK for a shortcut like that to be available only in simple cases.


Reply via email to