Front page | perl.perl6.language |
Postings from June 2005
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ß)Thread Previous | Thread Next