[OT] Perl woes

[Paul Makepeace]

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"'
yes
$ perl -le 'print "yes" if "1" == "1"'
yes
$ perl -le 'print "yes" if "1" == "0"'
$ perl -le 'print "yes" if "1" == 1'
yes
$

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
> automatically.
>
>
> 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.

http://cafe.elharo.com/blogroll/operator-overloading-considered-harmful/

I wouldn't use C++ as a model of the right way to do things...

P