[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Why 'if 0' succeeds in Ruby

Phlip

8/23/2008 5:02:00 PM

Rubiods:

One of the first "gotchas" here coming from another language is 0 is not like
'true'. This Daily WTF (which I think someone just posted here) illustrates the
problem which Ruby solves:

http://thedailywtf.com/Articles/pider-Dete...

"Rather than check the difference between 0 and FALSE (or use a more appropriate
function), the original developer just dropped the first letter of each crawler
name so that strpos doesn't return 0."

$spider_footprint = array('ooglebot', 'rawler', 'pider', 'ulliver',
'arvest', 'ahoo! Slurp');
foreach($spider_footprint as $spider_name)
{
if (strpos($agent, $spider_name))
{
$is_spider = 1;
....

The problem is not that the programmer did not want to add FALSE != . The
problem is that language treats 0 as false, when 0 positively means we have a
good value with a 0 inside it.

0 as FALSE is a legacy of languages that could not distinguish 0 and NULL.

So the Ruby version would work like:

if agent.index('googlebot')

So, once again, Ruby gives us the right defaults, precedents, and operations
that do much more, with much less code.

--
Phlip
20 Answers

Dave Bass

8/23/2008 5:31:00 PM

0

But unfortunately Ruby regards both false and nil as not-true. For some
reason, this is touted as a feature.

False and nil are two quite different concepts and should not be
conflated.
--
Posted via http://www.ruby-....

Jason Roelofs

8/23/2008 5:41:00 PM

0

On Sat, Aug 23, 2008 at 1:31 PM, Dave Bass <davebass@musician.org> wrote:
> But unfortunately Ruby regards both false and nil as not-true. For some
> reason, this is touted as a feature.
>
> False and nil are two quite different concepts and should not be
> conflated.
> --
> Posted via http://www.ruby-....
>
>

It's a perfectly fine feature and makes perfect sense if you
understand Ruby's object model. 0 is not nothing, it's Fixnum(0). Thus
it's an object, and not anything that can be differentiated from, say
2, 5 or "some string". Of course nil is NilClass and false is
FalseClass, which are also objects, but there needs to be something
that allows for if(false) checks, so those two classes are the special
cases. When taken as in context of Ruby as a whole, this of course
makes sense, as nil is effectively our nothing (like NULL / 0 in C and
C++) and FalseClass is our actual 'false'.

Jason

Phlip

8/23/2008 6:25:00 PM

0

Dave Bass wrote:

> But unfortunately Ruby regards both false and nil as not-true. For some
> reason, this is touted as a feature.
>
> False and nil are two quite different concepts and should not be
> conflated.

So the Ruby version would work like:

if agent.index('googlebot')

So, once again, Ruby gives us the right defaults, precedents, and operations
that do much more, with much less code.

If you need false==, to self-document with more code, go for it. Given the
choice of forcing you to conflate 0, FALSE, and NULL, and only conflating
two of them, Ruby picked the right two, for nearly all situations. If you
want Pascal or Ada, you know where to get them!

--
Phlip


David A. Black

8/23/2008 6:36:00 PM

0

HI --

On Sun, 24 Aug 2008, Dave Bass wrote:

> But unfortunately Ruby regards both false and nil as not-true. For some
> reason, this is touted as a feature.
>
> False and nil are two quite different concepts and should not be
> conflated.

They're not conflated, though. The two objects false and nil have in
common that they present as false, in the boolean sense, so that "if
false" and "if nil" both branch away. I think that's reasonable, since
otherwise you'd have to do a lot of "if (expr).nil? ||! expr" and
stuff like that. But they're still different objects, and the concepts
of falsehood and nilness are handled separately but converge at the
point of boolean value. The same is true of, say, the objects true and
"string".

It all comes down to the difference between being an object and having
a boolean "persona".


David

--
Rails training from David A. Black and Ruby Power and Light:
Intro to Ruby on Rails January 12-15 Fort Lauderdale, FL
Advancing with Rails January 19-22 Fort Lauderdale, FL
See http://www.r... for details and updates!

M. Edward (Ed) Borasky

8/24/2008 1:36:00 AM

0

On Sun, 2008-08-24 at 02:31 +0900, Dave Bass wrote:
> But unfortunately Ruby regards both false and nil as not-true. For some
> reason, this is touted as a feature.
>
> False and nil are two quite different concepts and should not be
> conflated.

Exactly! To make matters worse, Lisp "traditionally" treated nil as
false, but Scheme has "true", "false" and "nil" and nil is treated as
true in Scheme.

So I don't have a problem with 0 not being false, but I do have a
problem with nil being false in Lisp and Ruby and true in Scheme. 0 is
0, nil is nil, true is true and false is false and that is that!

:)
--
M. Edward (Ed) Borasky
ruby-perspectives.blogspot.com

"A mathematician is a machine for turning coffee into theorems." --
Alfréd Rényi via Paul ErdÅ?s

Charles Oliver Nutter

8/24/2008 2:14:00 AM

0

M. Edward (Ed) Borasky wrote:
> On Sun, 2008-08-24 at 02:31 +0900, Dave Bass wrote:
>> But unfortunately Ruby regards both false and nil as not-true. For some
>> reason, this is touted as a feature.
>>
>> False and nil are two quite different concepts and should not be
>> conflated.
>
> Exactly! To make matters worse, Lisp "traditionally" treated nil as
> false, but Scheme has "true", "false" and "nil" and nil is treated as
> true in Scheme.
>
> So I don't have a problem with 0 not being false, but I do have a
> problem with nil being false in Lisp and Ruby and true in Scheme. 0 is
> 0, nil is nil, true is true and false is false and that is that!

I tend to look at these things not from at the level of pedantic
consistency-mongering but in terms of what would be lost if the concept
were changed.

* a ||= x would no longer work, since unassigned a (nil) would not
evaluate to false causing x to be assigned.

* @a ||= x would no longer work

* a[n] ||= x would no longer work

* a.b ||= x would no longer work

"nil" being considered a boolean false seems absolutely natural to me,
and it makes possible a large number of concepts in Ruby we'd really miss.

- Charlie

David A. Black

8/24/2008 2:27:00 AM

0

Hi Ed --

On Sun, 24 Aug 2008, M. Edward (Ed) Borasky wrote:

> On Sun, 2008-08-24 at 02:31 +0900, Dave Bass wrote:
>> But unfortunately Ruby regards both false and nil as not-true. For some
>> reason, this is touted as a feature.
>>
>> False and nil are two quite different concepts and should not be
>> conflated.
>
> Exactly! To make matters worse, Lisp "traditionally" treated nil as
> false, but Scheme has "true", "false" and "nil" and nil is treated as
> true in Scheme.
>
> So I don't have a problem with 0 not being false, but I do have a
> problem with nil being false in Lisp and Ruby and true in Scheme. 0 is
> 0, nil is nil, true is true and false is false and that is that!
>
> :)

I understand what you're saying but I have a real, non-rhetorical
question: In practical terms, what do you think should be done about
such a situation? It seems to me that there are two possibilities:
either computer languages really do things differently, including
things like this (not just stylistic and/or cosmetic things), or they
don't and then they all become the same.

I can't think of a third possibility, and of course I like the first
better than the second :-)


David

--
Rails training from David A. Black and Ruby Power and Light:
Intro to Ruby on Rails January 12-15 Fort Lauderdale, FL
Advancing with Rails January 19-22 Fort Lauderdale, FL
See http://www.r... for details and updates!

Phlip

8/24/2008 4:34:00 AM

0

Charles Oliver Nutter wrote:

> * a ||= x would no longer work, since unassigned a (nil) would not
> evaluate to false causing x to be assigned.
>
> * @a ||= x would no longer work
>
> * a[n] ||= x would no longer work
>
> * a.b ||= x would no longer work

Exactly! a positively-written program should propagate value-objects, and
truths, as its booleans express. If you don't like that, then your code should
be more positive. Excess examples of 'if nil == q' or 'if false == q' are a sign
your program indulges in negativity.

So once again, a default Ruby behavior leads to better code style.

--
Phlip

Hongli Lai

8/24/2008 9:23:00 AM

0

Dave Bass wrote:
> But unfortunately Ruby regards both false and nil as not-true. For some
> reason, this is touted as a feature.
>
> False and nil are two quite different concepts and should not be
> conflated.

I've found that treating both nil and false as false to be the correct
behavior for most of my code. I've rarely written code where I *don't*
want nil to be treated as false. Furthermore, in by far most of the use
cases, I don't want to treat 0 as false.

In other languages, such as Perl, I end up having to write 'if
(!defined($foo) || $foo eq "0")' all the time. So I like Ruby's
behavior. Treating both nil and false as false covers most of the use
cases.
--
Posted via http://www.ruby-....

Stefan Rusterholz

8/24/2008 10:06:00 AM

0

Dave Bass wrote:
> But unfortunately Ruby regards both false and nil as not-true. For some
> reason, this is touted as a feature.
>
> False and nil are two quite different concepts and should not be
> conflated.

They aren't conflated. nil != false in ruby, but nil and false have the
same conditional value. Both are conditionally false. In my experience
this has been the right call by matz all the way.

Regards
Stefan (apeiros)
--
Posted via http://www.ruby-....