develooper Front page | perl.perl6.language | Postings from March 2005

Re: s/true/better name/

Thread Previous | Thread Next
Larry Wall
March 16, 2005 10:49
Re: s/true/better name/
Message ID:
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.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About