Forum: Ruby Zero is true, but it isn't

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
John J. (Guest)
on 2006-04-20 03:53
(Received via mailing list)
I was wondering today, so I tried this:

puts "It's true" if 0

Which prints "It's true", meaning 0 is not false. (This should surprise
C/C++/etc. people).

So that means
puts "It's equal" if 0 == true

but 0 != true. Although it seems it should be, since 0 != false as
well. So, by extension, if an object is not nil, and it is not equal to
false, then it would stand to reason that it is equal to true.

Any thoughts?

Regards,
   JJ

---
Help everyone. If you can't do that, then at least be nice.
Matthew M. (Guest)
on 2006-04-20 04:20
(Received via mailing list)
> So that means
> puts "It's equal" if 0 == true
>
> but 0 != true. Although it seems it should be, since 0 != false as
> well. So, by extension, if an object is not nil, and it is not equal to
> false, then it would stand to reason that it is equal to true.
>
> Any thoughts?

0 is not equal to true, but is implicitly converted to true.

Try:
puts "It's equal" if !!0 == true
unknown (Guest)
on 2006-04-20 06:10
(Received via mailing list)
Hi --

On Thu, 20 Apr 2006, John J. wrote:

> but 0 != true. Although it seems it should be, since 0 != false as well. So,
> by extension, if an object is not nil, and it is not equal to false, then it
> would stand to reason that it is equal to true.
>
> Any thoughts?

Every object has a Boolean value of true or false, separately from the
fact that there are objects called true and false.  The objects false
and nil have a Boolean value of false; all other objects have a
Boolean value of true (including true, integers, strings, etc.).

The result is that passing the "if x" test, on the one hand, and being
the object true, on the other, are not the same thing.


David

--
David A. Black (removed_email_address@domain.invalid)
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

"Ruby for Rails" PDF now on sale!  http://www.manning.com/black
Paper version coming in early May!
Xavier N. (Guest)
on 2006-04-20 11:27
(Received via mailing list)
On Apr 20, 2006, at 1:51, John J. wrote:

> I was wondering today, so I tried this:
>
> puts "It's true" if 0
>
> Which prints "It's true", meaning 0 is not false. (This should
> surprise C/C++/etc. people).
>
> So that means
> puts "It's equal" if 0 == true

You are seeing a particular case of the fact that the boolean
interpretation an object may be different from the object value
itself. And == is comparing object values, not boolean
interpretations. Then the result of == is interpreted in boolean
context, but by then 0 was seen as an integer already, which is
certainly different from the object true.

To make it apparent take "foo". The string "foo" is true in boolean
context, but it won't surprise you to realise that "foo" == true does
not hold.

-- fxn
Peter E. (Guest)
on 2006-04-20 12:26
(Received via mailing list)
$ irb

irb(main):001:0> true.class
=> TrueClass
irb(main):002:0> false.class
=> FalseClass
irb(main):003:0> 0.class
=> Fixnum

0 is not a boolean, so interpretation is up to the language.

Most common is 0 := false, 1 := true as you already know.
I think in Visual Basic it is 0 := false, -1 := true
Also possible 0 := false, not 0 := true

So it depends ... :-)
Austin Z. (Guest)
on 2006-04-20 16:06
(Received via mailing list)
On 4/20/06, Peter E. <removed_email_address@domain.invalid> wrote:
>
> Most common is 0 := false, 1 := true as you already know.
> I think in Visual Basic it is 0 := false, -1 := true
> Also possible 0 := false, not 0 := true

And the argument against 0 being false is shell scripts, where 0 is
true.

-austin
Logan C. (Guest)
on 2006-04-20 22:35
(Received via mailing list)
On Apr 20, 2006, at 3:26 AM, Xavier N. wrote:

>> puts "It's equal" if 0 == true
> does not hold.
>
> -- fxn

Wouldn't it be neat if true === worked with anything that is
interpreted as true

e.g.

case x
   when true
      ...
    else
      ...
end

Of course anyone would use an if statement in this situation, but it
is kind of conceptually clean and sort of matches up with Range#===,
Regexp#===, etc.
Robert D. (Guest)
on 2006-04-20 23:33
(Received via mailing list)
On 4/20/06, Logan C. <removed_email_address@domain.invalid> wrote:
>
>
>
>
> Wouldn't it be neat if true === worked with anything that is
> interpreted as true


You saved my day, I was really disappointed when I found that this code
was
missing from ruby

def TrueClass.===(other);other?true:false;end
def FalseClass.===(other);! true === other; end ### That 1 is ugly
def NilClass.===(other);! true === other; end

shall we make a CR or for Ruby2?

e.g.
> Regexp#===, etc.
Completely agree and if anyone uses an if statement why should we!!!!!

But I guess it is up to everyone to "fix" ruby for his own needs.

Cheers
Robert



--
Deux choses sont infinies : l'univers et la bêtise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.

- Albert Einstein
Logan C. (Guest)
on 2006-04-21 02:38
(Received via mailing list)
On Apr 20, 2006, at 3:32 PM, Robert D. wrote:

>> case x
>
> Completely agree and if anyone uses an if statement why should we!!!!!
>
> But I guess it is up to everyone to "fix" ruby for his own needs.
>
> Cheers
> Robert

Sorry if this is offensive, but since text doesn't really transmit
tone of voice, are you being sarcastic? I wasn't seriously suggesting
changing ruby in this manner, it was just sort of "this seems to jive
with the other uses of #=== for the cases where the lhs side of #===
represents a set of values". +true+ conceivably represents the set of
"true" values.
Robert D. (Guest)
on 2006-04-21 13:48
(Received via mailing list)
On 4/21/06, Logan C. <removed_email_address@domain.invalid> wrote:
>
>
>
> Sorry if this is offensive, but since text doesn't really transmit
> tone of voice, are you being sarcastic?


That is why I am never sarcastic unless with people who know me, see how
lucky U R.

I wasn't seriously suggesting
> changing ruby in this manner,


that is too bad, I thought you were :(

it was just sort of "this seems to jive
> with the other uses of #=== for the cases where the lhs side of #===
> represents a set of values". +true+ conceivably represents the set of
> "true" values.


The case idiom is so widespread look at it again
case value
    when something,
now something can meaningful be an instance of
Range, Regexp, Class, and many more
it cannot be an instance of TrueClass, FalseClass or NilClass.
Seems somehow unorthogonal, and you put it vert clearly and nicely, well
I
thaught.

With all due respect to Matz, having a TrueClass and a FalsClass with a
single instance each  (true and false for that matter) and them being
not
related whatsoever more than any other two objects * this point is often
overlooked * seems confusing at least.
Is there a good reason for it?
The design of a Doubleton class Boolean having true and false as values
seems so much preferable.
Seems just odd to me.

Well as a matter of fact we are OT.
The topic was why is 0 not treated as false when in such context.
I like it, especially the
!!"" == true thing is very useful.
Maybe the !!0 == true thing is less useful (BTW that is how I should
have
defined the #=== above ;).
So I am quite serious about that and

- I did not take any offence.

It is completely normal telling me "hey buddy you misunderstood what I
said", and moreover I am used to it.

Cheers
Robert




--
Deux choses sont infinies : l'univers et la bêtise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.

- Albert Einstein
John J. (Guest)
on 2006-04-24 19:15
(Received via mailing list)
On 20-Apr-2006, at 08:05, Austin Z. wrote:
>> Most common is 0 := false, 1 := true as you already know.
>> I think in Visual Basic it is 0 := false, -1 := true
>> Also possible 0 := false, not 0 := true
>
> And the argument against 0 being false is shell scripts, where 0 is
> true.
>

Perhaps 0 in this context is SUCCESS, and anything else is an error?

---
Help everyone. If you can't do that, then at least be nice.
John J. (Guest)
on 2006-04-24 19:21
(Received via mailing list)
Thanks to all who responded to my query.

Ruby is so magnificent, I would never dream of suggesting a change,
because, ultimately, it would probably somehow hose the principal of
least surprise that makes it so great.

Thanks again,
   JJ

On 20-Apr-2006, at 04:26, Peter E. wrote:
>> An: removed_email_address@domain.invalid (ruby-talk ML)
>>> surprise C/C++/etc. people).
>>
>> To make it apparent take "foo". The string "foo" is true in boolean
>> context, but it won't surprise you to realise that "foo" == true does
>> not hold.
>>
>> -- fxn
>>
>>
>
>

---
Help everyone. If you can't do that, then at least be nice.
This topic is locked and can not be replied to.