[OT] Perl woes
paulm at paulm.com
Wed Jan 28 12:01:22 GMT 2009
On Wed, Jan 28, 2009 at 11:31 AM, Dominic Thoreau
<dominic.thoreau at googlemail.com> wrote:
> 2009/1/28 Jonathan Kimmitt <Jonathan.Kimmitt at csr.com>:
>> The next time I use == instead of eq to compare two strings, I
>> will know to expect it will always
>> evaluate to true.
Interesting that everyone's said to "use warnings" but no-one's
questioned what you're saying. Perl appears to me to DTRT:
$ perl -le 'print "yes" if "a" == "2"'
$ perl -le 'print "yes" if "a" == "a"'
$ perl -le 'print "yes" if "1" == "1"'
$ perl -le 'print "yes" if "1" == "0"'
$ perl -le 'print "yes" if "1" == 1'
Can you give an example where perl is doing something surprising to you?
(python incidentally treats '1' != 1, but then it doesn't have
different operators for comparison.)
>> What other language does this (apart from C,
>> which would invariably return false)
> Unfortunately, this is perl being helpful. Because you've treated them
I'd say it's more of a legacy phenomenon that perl was permissive in
the beginning. You'd find very few people today recommending writing a
new perl program without "use warnings", and the above usage would
fire a warning which is effectively saying perl's original behavior
isn't desirable in the vast majority of cases.
> like numbers, they must be numbers, and the conversion will be done
> I'm taking a series of courses in Java (don't shun me for this - it's
> part of my OU degree), and I did comment the grumble to the tutor that
> it won't let you overload these operators yourself for your own
> objects (like, say, C++ will). His comment was that it was a trade
> off, sacrificing power in the hope that responsibility was also
> lessened, but I'm not sure it was a good design decision.
I wouldn't use C++ as a model of the right way to do things...
More information about the london.pm