$var = /$pattern/; probably isn't a bug. I've writen that plenty of times. I'd hate for people to read that and think I didn't actually mean assignment.

I'd hate for people to read that and think I didn't actually mean assignment.


Then don't write it that way:

foreach my $address (@email_addresses) {
    my $is_valid = $address =~ /[a-zA-Z0-0.]+\@[a-zA-Z0-0.]+/;

    if ($is_valid) {
        ....
    }
}
[download]

Seriously, if you're writing code for public consumption and think, "Gee, I hope who's ever reading this can understand it," then rewrite it so you're sure they'll be able to understand it, or comment it, or do both.

I just grepped my source repository to see where I'd written that and I couldn't find it. The general case I'd thought of where it was annoying or inconvenient to the narrative to give the topicalized variable a name. I can't find an example (though I did just find a code-typo in Switch.pm where ~= was said instead of =~).

for ( ... )
{
    $foo = /.../;
}
[download]

Well, I not only wouldn't use explicit loop variables when I can resort to the singular pronoun (or even better, when I can omit it) but I would also try to avoid unnecessary assignments ;-)

foreach (@email_addresses) {
    if ( /[a-zA-Z0-0.]+\@[a-zA-Z0-0.]+/ ) {
        ....
    }
}
[download]

This is IMHO more legible, as long as your public is fluent in Perl, or just knows the basics.
The only context where I would use your code is a Perl class, but just to show immediately after how to shorten that code and make it more legible (confess, you are a teacher! ;-)

Cheers,
Emanuele.

As long as $var was named something like $count, or possibly $matched, or the context itself gave this information then I would say its fine. If $var was actually $str or the like I would probably say it was a bug. If it said ($var)=/$pattern/ it would almost certainly be fine regardless.



---
demerphq


First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi

"is associated with" isn't any better than "binds" (or "is bound to").
There is no binding, there is no associating.
The expressions on the two sides of the =~ are simply arguments to a built-in function.

It is far more accurate to talk about "applying" the pattern to the string.
Or, for Jah's sake, why not simply "the string is tested against the pattern"?
"=~ is the pattern-applying operator."

If "=~ is the pattern applying operator", then code like if( /foo/ ) would never apply the regex. The two sides of =~ are *not* passed to some built-in function as arguments. The right-hand side is what is run and the left-hand side is the argument if it is present. An "unbound" regex still gets applied. Matching happens even without =~.

The =~ (mostly) is *not* what makes pattern matching happen. The regex is what makes pattern matching happen and the =~ (if present) binds a string to the regex to tell it what to match against (other than the default).

Now, if you have =~ with something that isn't a regex to its right, then you have rather bizarre code and are at the mercy of dubious "do what I mean" guessing. If Perl happens to currently insert a regex constructor for you, my main reaction is that I know I have no code that relies on such.

So the reason we say 'bind' is because one side is the code to run. Like '(' is used to bind arguments to a function -- '(' is not "the function invoking operator", despite that description being somewhat appropriate.

- tye