>But I agree that such examples would certainly make a better argument.
>The only concrete thing I can come up with is that I and several other
>perl coders I know had a lot of trouble remembering the =~ symbol. I've
>been a very frequent perl user for about 8 years, and after I didn't use
>perl for about a month (2 week vacation + intense pressure at work,
>it'll never happen again, I promise!), I couldn't for the life of me
>remember whether it was ~= or =~. I've also observed one perl beginner
>look up the symbol in a book every single time she needed it for a new
>program.
Changing anything that has ever or shall ever confuse anyone is a
task without end: you will never be done, so don't even start.
The =~ operator is perfectly obvious to csh programmers, of course,
which is where it came from. There can be no ~= operator because
that is obviously construing a binary ~ operator, which currently
remains nonexistent. The ~ operator is unary only, thus far.
Whether there *should* be a binary ~ operator, one related to pattern
matching, is a different question. The awkers expect there to be,
but you can't please all the people all the time. They've got
their !~, so hopefully this will semiappease them.
The occasionally proposed use for a binary ~ is mostly in conjunction
with a substitute or translit, so that it returns the new string
rather than the success count. The original would be unchanged.
# eg "fred & barney" or "wilma and barney"
if ( "barney" eq ($var ~ s/.*\W//) ) {
Or thus
$alteration = ($original ~ s/old/new/);
Which is really just like
($alteration = $original) ~= s/old/new/;
but might be better optimized. Sure would be nice if they en-passant
things would be better optimized anyway, though.
Seems to me that if ~ did this, then ~= might be a reasonable thing!
$foo = $foo ~ s/old/new/
could then of course be written
$foo ~= s/old/new/
which would in fact be the same as
$foo =~ s/old/new/
Whether this would actually be desirable is highly open to debate. :-)
--tom
