Front page | perl.perl6.language |
Postings from March 2005
Re: s/true/better name/
Thread Previous
|
Thread Next
From:
Larry Wall
Date:
March 16, 2005 10:49
Subject:
Re: s/true/better name/
Message ID:
20050316184853.GH27352@wall.org
On Wed, Mar 16, 2005 at 01:41:56PM -0500, Mark J. Reed wrote:
: Luke Palmer wrote:
:
: >Marcus Adair writes:
: >> Additionally I question whether this is truly a case improving to the
: >> point of least surprise? After all, I don't know a programmer who's
: >> going to be surprised by what true means. There are still *some* things
: >> you may have to learn in software dev 101 ;)
: >
: >The problem is this (common) one:
: >
: > if answer() == true {
: > # do something
: > }
: >
: >We want to give the programmer no good way to do that, because it's
: >wrong.
: >
:
: What do you mean "wrong"? It looks perfectly valid to me. It's
: redundant, since answer() by itself would suffice as a condition with no
: comparison, but does that make it wrong?
It could be forced to work if MMD is smart enough to call an ==
function that we were smart enough to define that is smart enough to
look at the .bit property of the left argument to coerce that value
to 0 or 1. But the naive implementation ends up comparing 42 == 1
and returning false. Unfortunately, == is one of those things we'd
like to optimize heavily, and it's hard if there's a lot of MMD
cruft in the way.
Larry
Thread Previous
|
Thread Next