HaloO Larry,

you wrote:
>  : Might I add that it should read
>  : 
>  :       $var = (&op.does(identval) ??
>  :               &op.identval($value) :: undef) op $value;
>  : 
>  : The rational is, that &op is subject to MMD, so the .identval method
>  : should be dispatched as well. Actually &op.identity($value) reads
>  : quite natural and self documenting if the parameter is required.
>  
>  I don't think there's a double dispatch there.

What do you mean with double dispatch? A single MMD on two arguments
or two dispatches after each other?


>   I think &op just knows
>  it can default its left argument to an existing attribute value if it
>  (somehow) knows it's part of an assignment op.  There's not a lot of
>  payback in getting all abstract here, as far as I can see.

Let's assume that op is overloaded for two completely unrelated types
A and B, which are both defining their respective identity elements
but !(A.identval =:= B.identval). How should the &op multi method object
pick the correct one *without* looking at $value's type? Or does the
indentval role force their takers to provide all infix ops with a
test for undef args and a fallback to the respective identity value?
If that is the case, the test for the role is superfluous. Or is the
intent to enforce a unique identity value for each operator like 0 for +
and 1 for *?

There's actually a second problem. Will the &op.does(identval) condition
be true or false if the &op multi contains some targets with and some
without an identval?

Finally I don't understand how the knowledge about a pending assignment
eases the choice problem for the multi. Note that the choice of
assignment operator depends on the return value of the operator and
the type of which the lhs is undef.

Regards,
-- 
TSa (Thomas SandlaÃ?)