P
Phlip
Giles said:if foo == "false"
can see the usefulness of this.
In which locales?
Giles said:if foo == "false"
can see the usefulness of this.
In which locales?
=20
sorry? I don't know what you mean.
everybody knows
if "false"
returns true. there are situations where that's a pain. I did a Rails
thing where I was creating objects and calling methods from options
hashes which I sometimes got by simply passing in params from a
controller and sometimes actually wrote as code. so I would have
@some_boolean = options[:some_boolean]
and five minutes later I'd be stubbing my metaphorical toe on an
if "false"
statement.
so I changed it to this:
@some_boolean = options[:some_boolean].to_b
and implemented #to_b by doing this:
class String
def to_b
case self
when "true"
true
when "false"
false
else
raise Exception
end
end
end
class FalseClass
def to_b
false
end
end
class TrueClass
def to_b
true
end
end
at that point I could pass in options hashes and it didn't matter
whether they came in properly and correctly as actual boolean values
or blustered in the servants' entrance as URL parameters.
what's weird to me about that is, it's so obvious, so useful, and so
trivial that I don't understand why it isn't the language to begin
with. obviously it comes from the inspiration of #to_s, #to_i, etc.
anyone who's ever written
if foo == "false"
can see the usefulness of this.
Lloyd said:This seems a bit silly to me. Â The language of Ruby is far more English
than any other language. Â Would this be of any use:
"false" == false.to_s
Michael said:sorry? I don't know what you mean.
I think he was trying to gently point out that "false" is English, so it's
likely to be the kind of problem only an English speaker would have. (Not
that I can say I've ever had this problem of confusing false with "false"
in *ANY* language.
everybody knows
if "false"
returns true. there are situations where that's a pain. I did a Rails
thing where I was creating objects and calling methods from options
hashes which I sometimes got by simply passing in params from a
controller and sometimes actually wrote as code. so I would have
@some_boolean = options[:some_boolean]
and five minutes later I'd be stubbing my metaphorical toe on an
if "false"
statement.
so I changed it to this:
@some_boolean = options[:some_boolean].to_b
and implemented #to_b by doing this:
class String
def to_b
case self
when "true"
true
when "false"
false
else
raise Exception
end
end
end
class FalseClass
def to_b
false
end
end
class TrueClass
def to_b
true
end
end
at that point I could pass in options hashes and it didn't matter
whether they came in properly and correctly as actual boolean values
or blustered in the servants' entrance as URL parameters.
what's weird to me about that is, it's so obvious, so useful, and so
trivial that I don't understand why it isn't the language to begin
with. obviously it comes from the inspiration of #to_s, #to_i, etc.
anyone who's ever written
if foo == "false"
can see the usefulness of this.
--
Giles Bowkett
Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com/
Bob said:puts "one" if s
puts "two" if false == s
puts "three" if "false" == s
puts "four" if ("false" == s) and (false == s)
puts "five" if s and "FALSE"
puts "seven" if s.equal?(s2)
puts "eight" if s.equal?(false)
Phlip said:
everybody knows
if "false"
returns true. there are situations where that's a pain. I did a Rails
thing where I was creating objects and calling methods from options
hashes which I sometimes got by simply passing in params from a
controller and sometimes actually wrote as code. so I would have
@some_boolean = options[:some_boolean]
and five minutes later I'd be stubbing my metaphorical toe on an
if "false"
statement.
so I changed it to this:
@some_boolean = options[:some_boolean].to_b
and implemented #to_b by doing this:
class String
def to_b
case self
when "true"
true
when "false"
false
else
raise Exception
end
end
end
everybody knows
if "false"
returns true. there are situations where that's a pain. I did a Rails
thing where I was creating objects and calling methods from options
hashes which I sometimes got by simply passing in params from a
controller and sometimes actually wrote as code. so I would have
@some_boolean = options[:some_boolean]
and five minutes later I'd be stubbing my metaphorical toe on an
if "false"
statement.
so I changed it to this:
@some_boolean = options[:some_boolean].to_b
and implemented #to_b by doing this:
class String
def to_b
case self
when "true"
true
when "false"
false
else
raise Exception
end
end
at that point I could pass in options hashes and it didn't matter
whether they came in properly and correctly as actual boolean values
or blustered in the servants' entrance as URL parameters.
This seems a bit silly to me. The language of Ruby is far more English
than any other language.
Would this be of any use:
"false" == false.to_s
everybody knows
if "false"
returns true. there are situations where that's a pain. I did a Rails
thing where I was creating objects and calling methods from options
hashes which I sometimes got by simply passing in params from a
controller and sometimes actually wrote as code. so I would have
@some_boolean = options[:some_boolean]
and five minutes later I'd be stubbing my metaphorical toe on an
if "false"
statement.
so I changed it to this:
@some_boolean = options[:some_boolean].to_b
and implemented #to_b by doing this:
class String
def to_b
case self
when "true"
true
when "false"
false
else
raise Exception
end
endat that point I could pass in options hashes and it didn't matter
whether they came in properly and correctly as actual boolean values
or blustered in the servants' entrance as URL parameters.
This proposal, and the responses (the negative ones) I find
interesting, because I think it highlights a "problem" with most of
the #to_blah methods, especially on String.
If you can accept "32".to_i == 32 or "1.0".to_f == 1.0 (pretend for a
moment theres no such thing as floating point inaccuracy ) then it
seems perfectly reasonable to accept "true".to_b == true. I think
what's throwing people is that string doesn't need an additional
method to be used in a boolean context, and they find the (if I may
use the word) "cast" distasteful. the #to_blah methods aren't "cast"s
they are conversions and so from that point of view I see nothing
wrong with #to_b.
On the other hand, I think your implementation is
flawed. #to_blah methods don't raise exceptions if they can give you
some value. E.g.: "google".to_i #=> 0. It doesn't raise an exception.
So I would pick one of (true, false) to be the result of
"gooble".to_b.
Robert said:Like this one?
class String
def to_b() self != "false" end
end
Not bad but I am thinking that, with people saying that they want to
have a wide assortment of what constitutes true, that they should make a
list (array) of things which would evaluate to true and anything else
would be false. But that is so individual that making it part of the
language seems counter productive.
I am thinking that, with people saying that they want to
have a wide assortment of what constitutes true, that they should
make a list (array) of things which would evaluate to true and
anything else would be false. But that is so individual that
making it part of the language seems counter productive.
Chiming in here to say that this paragraph is an awesome way of
describing the way things seem.
Robert said:I am not sure: Ruby originated in Japan and has a strong Japanese
community AFAIK. You may not have notice because Matz, Nobu and all the
others are kind enough to use English when they post here.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.