Bugger. I mean !@milk_volume.zero? of course. So this whole problem could
be avoided by making 0==false, thus proving your point. THIS is why I don’t
post normally…
Bugger. I mean !@milk_volume.zero? of course. So this whole problem could
be avoided by making 0==false, thus proving your point. THIS is why I don’t
post normally…
Haha… well, the got-milk logic would mean that negative numbers
would also be false, right? “I’ve got -5 gallons of milk. Give me
5 gallons, and I still won’t have any!”
Now you’ve got me thinking about the Mad Hatter’s tea party…
David Naseby (david.naseby@eonesolutions.com.au) wrote:
def got_milk? @milk_volume.zero?
Bugger. I mean !@milk_volume.zero? of course. So this whole problem could
be avoided by making 0==false, thus proving your point. THIS is why I don’t
post normally…
nonzero? returned nil instead of false for me. Shouldn’t it return false?
Eric Hodel wrote:
···
David Naseby (david.naseby@eonesolutions.com.au) wrote:
def got_milk? @milk_volume.zero?
Bugger. I mean !@milk_volume.zero? of course. So this whole problem could
be avoided by making 0==false, thus proving your point. THIS is why I don’t
post normally…
Returns num if num is not zero, nil otherwise. This behavior is useful
when chaining comparisons:
a = %w( z Bb bB bb BB a aA Aa AA A )
b = a.sort {|a,b| (a.downcase <=> b.downcase).nonzero? || a <=> b }
b » [“A”, “a”, “AA”, “Aa”, “aA”, “BB”, “Bb”, “bB”, “bb”, “z”]
nonzero? returned nil instead of false for me. Shouldn’t it return false?
8< ----- snip -----
No. From the pickaxe:
nonzero? num.nonzero? → num or nil
Returns num if num is not zero, nil otherwise. This behavior is useful
when chaining comparisons:
a = %w( z Bb bB bb BB a aA Aa AA A )
b = a.sort {|a,b| (a.downcase <=> b.downcase).nonzero? || a <=> b }
b » [“A”, “a”, “AA”, “Aa”, “aA”, “BB”, “Bb”, “bB”, “bb”, “z”]
Well, it’s just a matter of grammar. zero? could have been implemented
as returning nil or or 0 (since 0 is true), but that’s not as neat and
tidy as true/false. On the other hand, nonzero? returns nil or the
actual number, and nil/number is a better pair than false/number. From
the programmer’s view, it’s neater to have false/true and nil/value
pairs, and unless you do something like
if num.nonzero? == false
instead of
if num.zero?
then you won’t really notice the difference. Cheers!
-C
nonzero? returned nil instead of false for me. Shouldn’t it return false?
8< ----- snip -----
No. From the pickaxe:
nonzero? num.nonzero? → num or nil
Returns num if num is not zero, nil otherwise. This behavior is useful
when chaining comparisons:
a = %w( z Bb bB bb BB a aA Aa AA A )
b = a.sort {|a,b| (a.downcase <=> b.downcase).nonzero? || a <=> b }
b » [“A”, “a”, “AA”, “Aa”, “aA”, “BB”, “Bb”, “bB”, “bb”, “z”]
I’ve said this elsewhere in the thread, so just briefly here: true/false can
possibly be considered not as basic as nil/object; true and false would then
be seen as a secondary representation of that dichotomy, for convenience.
See [ruby-talk:100755].
Nicholas Van Weerdenburg> nonzero? returned nil instead of false for me.
Shouldn’t it return false?
Claus Spitzer > No. From the pickaxe:
I’ve said this elsewhere in the thread, so just briefly here: true/false can
possibly be considered not as basic as nil/object; true and false would then
be seen as a secondary representation of that dichotomy, for convenience.
See [ruby-talk:100755].
There’s no nil/object dichotomy, though; nil is an object. It’s handy
for flagging certain conditions (like failure, as in Regexp#match),
but that’s just a matter of convention; nil itself is still fully an
object.
I found this problem thorny when trying to export true/false to a
database that does not support booleans (only int). So I wrote a class
that magically does the conversion coming and going. Other than that, I
find nil a very useful value and nice to be separate from numbers.
Dan
···
On May 20, 2004, at 20:58, David A. Black wrote:
Hi –
On Fri, 21 May 2004, Dave Burt wrote:
I’ve said this elsewhere in the thread, so just briefly here:
true/false can
possibly be considered not as basic as nil/object; true and false
would then
be seen as a secondary representation of that dichotomy, for
convenience.
See [ruby-talk:100755].
There’s no nil/object dichotomy, though; nil is an object. It’s handy
for flagging certain conditions (like failure, as in Regexp#match),
but that’s just a matter of convention; nil itself is still fully an
object.
I found this problem thorny when trying to export true/false to a
database that does not support booleans (only int). So I wrote a class
that magically does the conversion coming and going. Other than that, I
find nil a very useful value and nice to be separate from numbers.
def find_converter(obj, target)
if target
obj.class.ancestors.each do |cl|
x = CONVERSIONS[ [cl, target] ]
return x if x
end
else
obj.class.ancestors.each do |cl|
x = CONVERSIONS[cl]
return x if x
end
end