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
