Paul Seamons skribis 2005-04-25 11:12 (-0600):
> By this reasoning - why have a shortcut to any of the invocants at all? This
> thread has headed in the direction of finding a way to figure out how to call
> methods on the invocant without using the signatures name. On a method call
> without a signature and without invoking Perl5isms there would not be a "way
> back" to the invocant once you enter nested block.
> The point of all of this discussion is to not have to set $self to anything.
> The argument for .meth as opposed to $self.meth of $_.meth was that .meth was
> clear enough to mean the current topic and was a nice huffmanization.
Agreed, but you put it as if there was no way of getting there, instead
of there being a way that isn't satisfactory.
I agree that having a short way to use the invocant is good, and like
your $^ proposal. I still don't understand what the "second invocant"
could be, though.
Another character that has no prefix meaning yet is >. <> are a bit
overused already, but perhaps this can fit in. It has the benefit of
being shift+dot on a US keyboard :P
> That works great - so long as I specify the signature. I'm lazy, I
> don't want to type the signature all the time. Consider:
When will people realise that this "problem" is exactly the same thing
as what you get when two other topicalizers are nested, and TREAT it
like exactly the same problem, so that a solution can be invented that
solve both "problems" in one stroke.
This said, I really do think the ^ thing is nice. But if you really
think not having a short syntax to reach something in a higher level
block is a problem, then be consistent and declare nested given/for
blocks a problem too. The "current invocant" problem is really not that
much different from the "outer topic" "problem", or, in larger scope,
the "outer block" problem, which is solved with labels.
outer topic problem name it, or use OUTER::
outer block problem name it (label it)
invocant problem name it! or use $?SELF
The same problem comes up whenever things can nest. So I'm more or less
expecting discussion about
outer rule problem
outer class|grammar problem (?)
parent process %ENV problem (learn to live with it)
parent object problem (familiar...)
Whether or not naming it is the answer in every occassion is a good
question. Probably when dealing with parent stuff, it is not, because we
want those things to be anonymous more often than the other things.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
