Larry Wall writes:
> : 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.
Well, except that you do have to memorize a list. But, yeah, you
basically do have to memorize a list of all MMD functions that take
junctions... so, I guess, sortof....
> : 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?
That's not what I'm talking about. I'm just saying that .val is the one
method that doesn't delegate when you're an iterator:
$i ==> the iterator
$i.val ==> the iterator without delegation ability
$i.val.deref ==> what the iterator points to without the .val method
It's just a way of making things concrete in delegates so that they
delegate in all but one simple case (for when you need to talk to the
delegate itself).
What I'm really worried about is:
my $meth = get_method(); # say it returns "values"
my $rets = (1|2).::($meth);
And instead of getting a junction in $rets like you would for *any other
method*, you get a list. It's a spooky, inconsistent,
hard-to-work-around special case.
And come to think of it, .val doesn't really solve that either.
You can see why I wanted syntactic support :-)
I don't really care how ugly it is though, I just want it. If we can
make it into a method or routine or something, that's fine, as long as
we can get it consistent. No, not consistent, *predictable*.
Note that with delegate-style iterator semantics, it is *not possible*
to manipulate an iterator through another iterator. There's some famous
Perl quote about things being possible...
> Except that S12 currently has that as var() instead of tied().
Cool.
