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.
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.
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.
I don't think $foo.\bar() is really going to work. It doesn't fit
together logically. Adding a \ after the dot seems to be saying
something about the method, when you're actually saying something about
the invocant. Plus, it means that you can do:
$foo.bar.\baz();
And what does that mean? That thing doesn't even have a container yet.
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.
Luke
