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 {...}
etc.
}
}
}
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
parameters.
Yes, and I think it's OK for a shortcut like that to be available only
in simple cases.
-David
