HaloO,
I'll just use what Paul Seamons wrote:
Consider:
method foo { .do_one_thing .and_another_thing map { $_.do_something_with( .bar ) } .items; # .bar worked on the invocant - not the items .and_the_last_thing }
because I don't have to invent examples on my own---thanks Paul!
My idea is to steal the postfix : from labels and use a keyword there. I propose 'land', which nicely fits 'goto hell' with 'land hell'. But linguistics is Larry's department. Actually these might be just be yet another control flow pair.
Then the above example could become:
BTW: don't the statements need termination/separation with semicolon?
method foo
{
.do_one_thing;
.and_another_thing;
map { do_something_with: .bar } .items;
# .bar worked on the invocant - not the items
# map { do_something_with $_: $invocant.bar } .items
.and_the_last_thing # here semicolon is optional
}the absence of . in front of do_something_with is easily spotted by an eye trained to Perl6 method code while the same applies to the : which indicates an indirect object and thus syntactically linked to the dynamic dispatcher.
It seems that the "oc behavior" and the ".method acts on $_" are huffmanized the wrong direction.
Hmm, outside of methods .method is just an operator that can be parsed generically---without declaration that is. So dot to me is the method sigil:
&method means closure variable $method means variable .method means postfix operator (needs explicit lhs) .$method means operator ref (e.g. $method = &postfix:<++>)
method: means method call with $_ passed in as invocant $method: same via method ref
method means predeclared sub/multi call (or generic listop?) method() same method $x: indirect object syntax meaning $x.method
In method scope no invocant is needed as lhs because it is the invocant:
$.method means public instance variable (from lexical class environment) .method means public method on invocant .$method means public method ref on invocant $:method means private instance variable :method means private method on invocant :$method means private method ref on invocant
The more I think about it the more I think the current behavior of .method on $_ is wrong. I don't think you should be able to dynamically set the invocant. Consider the danger of:
method foo { some_sub_bar(); .do_something();
I agree. If the programmer of the method wants to dispatch do_something as usual she could leave out the dot. But whatever happens in there it should not be able to modify the method's invocant.
BTW, is there a $?SELF for methods and @?SELF for multi methods? And are the following multi calls:
($x, $y, $z).multimethod; @array.multimethod; # might interfere with container methods
or is that syntax too weird?
# this now does get_some_other_object.do_something() }
Of course do_something() could change $_ but that is no surprise. The invocant variable is off-limits. In an abstract sense a method is not mutating it's self but rebinds the value that $?SELF is referring to.
As a side effect of not binding $_ to the invocant, the method can easily check if it was invoked on the topic with $_ =:= $?SELF --- "Wait a moment, are you talking about me?".
Regards, -- TSa (Thomas Sandlaß)
