On Sat, Dec 04, 2004 at 10:25:49AM -0700, Luke Palmer wrote: : Ashley Winters writes: : > For several reasons, that doesn't work for me. The method conflict : > between container methods and value methods should be obvious. What : > should ((1|2)|(3&4)).values return? : : Well, there is an answer, and it's one I've never been extremely happy : with. That is, Junctions delegate everything to their junctands : *except* a small set of methods. .values is one of those. So: : : ((1|2)|(3&4)).values returns (1|2), (3&4) : : And you can call values on each of those to get the others out. : : In my proposal "The Object Sigil", I attempted to get around this : problem for both Junctions and iterators, using a syntactic convention. : I later realized that you could do this with just one method. : Presumably this method would be called the same thing for everything, : let's say .val. : : Then: : : ((1|2)|(3&4)).values returns : ((1|2).values | (3&4).values) which returns : (1.values | 2.values) | (3.values & 4.values) which is an error : : So instead you'd use: : : ((1|2)|(3&4)).val.values : : You can see why I wanted syntactic support. : : But this convention provides much more accuracy than memorizing a list : of methods that don't automatically thread, or memorizing a list of : iterator methods that act on the iterator and not its current value.
Except that you don't actually have to memorize a list. Methods thread on their invocant only if their invocant isn't a Junction. Its mnemonic value is no better or worse than any other MMD distinction. : That is: : : for @foo -> $i { : $i.next; # call .next on the current value in @foo : $i.val.next; # call .next on the iterator : : # let's say @foo is a list of iterators! : $i.next; # call .next on the value pointed to by the iterator in @foo : $i.val.next; # call .next on the iterator $i : $i.val.deref.val.next; # call .next on the iterator in @foo : } : : Yeah, the last one is a mouthfull, but let's see you do that *at all* : with the other semantics. We can't have semantics where an object keeps track of what container it's in. What if it's in more than one container? The only reason a tied()-like operator works is that it's not really a run-time operator at all. : Anyway, there's something to think about. Moving on... : : > The answer is simple enough: for scalar container method calls, use : > $foo.\bar(), which would be syntactic sugar for (\$foo).bar, and would : > be the Perl6 equivalent to the Perl5 idiom tied($foo)->bar() : : Er, hmm. See, that doesn't solve your junction problem. Junction is a : value, and it's different from the scalar container it goes in. : : Differentiating method calls on arrays and hashes and on their values is : easy: : : @array.sort; : @array[0].sort; : : It's scalars which are the problem. /A1?2/ said that you actually do : use: : : tied($foo).bar; : : So, well, there you go. Except that S12 currently has that as var() instead of tied(). : It'd be nice to have some nicer way than tied($foo).bar, though. I : think we should see how often it comes up in the real world (or the : theoretical world) before we jump to adding a new operator on it. Agreed. Larry