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
Hi,
why "false" would be false when "" is true ?
There are just 2 values for false : nil and false.
Others would introduce confusion...
Use a function/method to convert your string in boolean with some
rules,
but don't change the ruby philosophy !
< of course, it's just my opinion >
···
Le samedi 08 septembre 2007 à 11:01 +0900, Giles Bowkett a écrit :
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
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.
You are also going to have to handle 'nil'.
What happens when you say:
s = "false"
s2 = "false"
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)
and so on to much more imaginative -- and bug-like I'm afraid -- constructs. Don't think of the examples too literally, what if you don't know what the values s and s1 are or could be. Actually wouldn't the requirement to (remember to) fix up the boolean operations be at least as tricky and error prone as the requirement to (remember to) modify #eql? when modifying the #hash can be? And what's the complete list of those anyway?
And don't forget about $= (and case insensitive comparisons, it's only been deprecated)
This makes more sense as #to_bool, and certainly not default
conditional behavior. Yet, a #to_b to dictate conditions could be
useful, allowing us to create our own variants of Nil. However, the
only alternate to Nil I've ever found useful is Null (nil that returns
itself on method_missing) --so I'd be pretty happy if we just had
that. Also, I believe there's a efficiency issue with using #to_b for
conditions, which is why it is never considered.
T.
···
On Sep 7, 7:01 pm, "Giles Bowkett" <gil...@gmail.com> wrote:
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
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.
···
On 9/7/07, Giles Bowkett <gilesb@gmail.com> wrote:
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.
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)
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 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.
Yeah, but the problem to solve in this case is a bit different: we are talking about input parameter conversion which is IMHO an application specific thing. For me that's at least part of the reason to *not* handle this by a general purpose conversion method.
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.
Like this one?
class String
def to_b() self != "false" end
end
Kind regards
robert
···
On 08.09.2007 17:16, Logan Capaldo wrote:
On 9/7/07, Giles Bowkett <gilesb@gmail.com> wrote:
Sorry, I momentarily had gotten the convention backward. You are
right, #to_b is the correct method, not #to_bool. #to_bool would make
sense for effecting conditionals though, not #to_b.
T.
···
On Sep 8, 7:54 am, Trans <transf...@gmail.com> wrote:
This makes more sense as #to_bool, and certainly not default
conditional behavior. Yet, a #to_b to dictate conditions could be
useful, allowing us to create our own variants of Nil. However, the
only alternate to Nil I've ever found useful is Null (nil that returns
itself on method_missing) --so I'd be pretty happy if we just had
that. Also, I believe there's a efficiency issue with using #to_b for
conditions, which is why it is never considered.
Ah. This is a good example for demonstrating what I meant. To fit into
Ruby convention, only TrueClass, FalseClass and NilClass (and things
like NullClass) should respond to to_bool. The String method should be #to_b, because it is not a true "Boolean" type.
T.
···
On Sep 10, 11:16 am, Sharon Rosner <cico...@gmail.com> wrote:
On Sep 8, 5:01 am, "Giles Bowkett" <gil...@gmail.com> wrote:
> everybody knows
> if "false"
> returns true.
class Object
def to_bool
case self
when true, false: self
when nil: false
else
to_i != 0
end
end
end
class String
TRUE_REGEXP = /^(yes|true|on|t|1|\-1)$/i.freeze
FALSE_REGEXP = /^(no|false|off|f|0)$/i.freeze
def to_bool
case self
when TRUE_REGEXP: true
when FALSE_REGEXP: false
else
to_i != 0
end
end
end
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.
···
On Sat, 2007-08-09 at 13:40 +0900, Giles Bowkett wrote:
> > if foo == "false"
> >
> > can see the usefulness of this.
>
> In which locales?
sorry? I don't know what you mean.
--
Michael T. Richter <ttmrichter@gmail.com> (GoogleTalk:
ttmrichter@gmail.com)
Experts in advanced countries underestimate by a factor of two to four
the ability of people in underdeveloped countries to do anything
technical. (Charles P Issawi)
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.
> > if foo == "false"
> >
> > can see the usefulness of this.
>
> In which locales?
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.
Yeah, in that case teh Hash based approach seems more appropriate.
Kind regards
robert
···
On 08.09.2007 18:17, Lloyd Linklater wrote:
Robert Klemme wrote:
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.
... but only after successful requiring, so you actually *have* to
properly close the quote.
robert
···
2007/9/10, Lloyd Linklater <lloyd@2live4.com>:
Phlip wrote:
> Todd Burch wrote:
>
>> Darn. I was hoping to get a #to_binary added to Ruby with all the
>> #to_b talk.
>
> Puh-leeze. "Binary" is soo Last Millenium.
If we are going for really cool new tech, how about
/set bugs OFF
or even a
require 'do_what_i_mean
p.s. I know I left off the closing single quote, but it knows what I
mean.
>