> Going back to patterns, this gives us an added bonus. It not only
> explains the behavior of hypotheticals, but also of subexpression
> placeholders, which are created when the pattern returns:
>
> $self but lexicals(0=>$self, 1=> $self.{1}, 2=> $self.{2}, etc...)
>
> That yields the side effect that you can say:
>
> sub match_digits($string //= $_) {
> return / (\d+) /;
> }
> if match_digits("The time is 12:03") {
> print $1;
> }
>
> I think this is a very clean and simple way to get everything that
> patterns were supposed to do plus a lot of added benefit for things
> like:
>
> sub getpwuid(int $uid //= $_) {
> %pwd = external("getpwuid",$uid);
> return %pwd but lexicals(%pwd);
> }
> getpwuid($<);
> print "I am $user from $dir, and I have a secret ($passwd)\n";
>
> You should be able to "protect" yourself from these side effects. There
> are two ways to do that:
>
> {getpwuid($<)}
>
> or
>
> getpwuid($<) but lexicals();
>
> I would expect either one of those to work, though the second is a bit
> of magic in terms of order of events.
This does bring up an interesting point. I think your solution is an
interesting idea, but not really necessary. But consider this:
my $date;
# lots of code
sub foo {
#lots more code
sub bar {
#lots more code
m/ $date := <date> /;
}
}
This is terrible. Calling foo which calls bar mysteriously overwrites
$date? "Why is $date changing?" the programmer asks. He does an
exhaustive search through his code and finally says "ohhhhhh," and has to
change all references to the inner $date to something like $mydate.
This is obviously a problem (unless I misunderstood how hypotheticals
change their surrounding scope). For a solution, let's just look how we
do it in subroutines.
my $date;
sub foo {
my $date = 'Jul 17, 1984';
# ...
}
Oh. Duh. Why don't we have such a mechanism for matches?
m/ my $date := <date> /
is ambiguous to the eyes. But I think it's necessary to have a lexical
scoping mechanism for matches, as to avoid the problem I addressed above.
Any ideas?
Luke