#to_b - why isn't this one already in there?

G

Giles Bowkett

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/
 
M

Michael T. Richter

--=-6+TTYLKFOLlnKG/gMi78
Content-Type: multipart/alternative; boundary="=-rgkOQMqTSoynGIowu23F"


--=-rgkOQMqTSoynGIowu23F
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

=20
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.

--=20
Michael T. Richter <[email protected]> (GoogleTalk:
(e-mail address removed))
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)

--=-rgkOQMqTSoynGIowu23F
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; CHARSET=3DUTF-8">
<META NAME=3D"GENERATOR" CONTENT=3D"GtkHTML/3.12.1">
</HEAD>
<BODY>
On Sat, 2007-08-09 at 13:40 +0900, Giles Bowkett wrote:
<BLOCKQUOTE TYPE=3DCITE>
<PRE>
<FONT COLOR=3D"#000000">&gt; &gt; if foo =3D=3D &quot;false&quot;</FONT>
<FONT COLOR=3D"#000000">&gt; &gt;</FONT>
<FONT COLOR=3D"#000000">&gt; &gt; can see the usefulness of this.</FONT>
<FONT COLOR=3D"#000000">&gt;</FONT>
<FONT COLOR=3D"#000000">&gt; In which locales?</FONT>

<FONT COLOR=3D"#000000">sorry? I don't know what you mean.</FONT>
</PRE>
</BLOCKQUOTE>
<PRE>

</PRE>
I think he was trying to gently point out that &quot;false&quot; is English=
, so it's likely to be the kind of problem only an English speaker would ha=
ve.&nbsp; (Not that I can say I've ever had this problem of confusing false=
with &quot;false&quot; in *ANY* language.<BR>
<BR>
<TABLE CELLSPACING=3D"0" CELLPADDING=3D"0" WIDTH=3D"100%">
<TR>
<TD>
-- <BR>
<B>Michael T. Richter</B> &lt;<A HREF=3D"mailto:[email protected]">ttmri=
(e-mail address removed)</A>&gt; (<B>GoogleTalk:</B> (e-mail address removed))<BR>
<I>Experts in advanced countries underestimate by a factor of two to four t=
he ability of people in underdeveloped countries to do anything technical. =
(Charles P Issawi)</I>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>

--=-rgkOQMqTSoynGIowu23F--

--=-6+TTYLKFOLlnKG/gMi78
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQBG4i2ULqyWkKVQ54QRArjzAJ0bqRr2GtlqGtqnNmuQcvIS+jS9YgCgny1K
0muqGwmTzbE4MF/VqphUN/U=
=ZtC5
-----END PGP SIGNATURE-----

--=-6+TTYLKFOLlnKG/gMi78--
 
D

dohzya

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

if foo == "false"

can see the usefulness of this.

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 ;) >
 
P

Phlip

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

Quoting Joel Spolsky, "There's no such thing as raw text".
 
P

Phlip

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.

Si.
 
B

Bob Hutchison

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.

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)

Cheers,
Bob

----
Bob Hutchison -- tumblelog at http://
www.recursive.ca/so/
Recursive Design Inc. -- weblog at http://www.recursive.ca/
hutch
http://www.recursive.ca/ -- works on http://www.raconteur.info/
cms-for-static-content/home/
 
P

Phlip

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)

p YAML::load('false')
 
L

Lloyd Linklater

Phlip 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
 
T

Trans

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 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.
 
L

Logan Capaldo

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 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.
 
R

Robert Klemme

This seems a bit silly to me. The language of Ruby is far more English
than any other language.

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. :)
Would this be of any use:
"false" == false.to_s

I'm not sure what you try to point out. If you are referring to the
fact that false returns "false" when invoking #to_s (which is locale
unaware) then I'd say this is a different story: one string
representation *has* to be chosen and what would be more natural than
using the same wording?

Conversion of values obtained from user input or something similar is a
completely different story because these will usually be in a particular
language which often depends on the user. Note that, if I'm not
mistaken, browsers can send anything for marked checkboxes and
radiobuttons in forms so the proper distinction might rather be present
and not present. (Dunno how Rails handles this though).

Another note: I am increasingly reluctant to modify core classes to
achieve specialized behavior like this. A simple method called on the
result of the Hash lookup would have served the same purpose. An even
more efficient solution would use a Hash for conversion:

# one variant
BOOL = Hash.new {|h,k| k}.merge("false" => false)

Kind regards

robert
 
R

Robert Klemme

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 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
 
L

Lloyd Linklater

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.
 
R

Robert Klemme

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.

Yeah, in that case teh Hash based approach seems more appropriate.

Kind regards

robert
 
G

Giles Bowkett

The thing I like about the approach I took is that it doesn't
generalize to any other context. It only does one thing. I'm using it
in a constructor which takes a hash. Sometimes the hash is built by
code, and sometimes it's a params hash in Rails - in other words, a
set of Strings - with a few additional values merged in. It's pretty
common in Ruby to use a hash as a substitute for keyword arguments to
methods, and that's what's happening here. The code gets kind of
wiggy, and it makes it really nice when the params specified in a URL
or a form post line up exactly with the "keyword arguments" so that
there's no unnecessary synonyms clouding the semantic space. you
basically get semantic URLs this way internally to your application.
but if you want to use a boolean in this context, you have to convert
it, and circumvent that whole

if "false" # => true

gotcha.

this isn't actually related to human language **at all**. if you're
attempting to use URL parameters as keyword arguments, you want the
URLs to look just like Ruby, but of course the values in a URL or in
form parameters can actually only move out to the Web or come back
from it as strings. false doesn't come in as the string "false"
because I speak English. it comes in as the string "false" because
**Ruby** speaks English. if Ruby used the word "falso" or for that
matter "nothos," transliterating Ruby literals into strings would mean
using "nothos" or "falso" also. it's got nothing to do with locales.
it's got to do with being able to seamlessly transliterate your code
into URLs for the Web and get it back in executable form.

ok, apologies if that's somewhat defensive. I'm just saying, a lot of
the critiques sound dead on, but in this case I totally stand by my
design. in the broader case, I'm used to this from Perl, where the
scalar "false" also evaluates to true. but one of the huge strengths
of Ruby is that it keeps a lot of Perl's power and flexibility, but
throws away the weird, nearly demented idiosyncrasies. I can't be the
first person who ever coded a solution like this, and I know that
to_i exists because your code can get numbers in as Strings or Floats
or what have you and need to convert it before doing anything real
with it.

(probably I should just STFU and package this up as a microgem or what
have you.)

anyway I think this is probably the answer:
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 think the reason it's not part of the language is that you
**should** alter the language for specific things. I kind of
overloaded on Perl and went to Java and Python, and I actually found
the stability of those languages a nice change. so when I got into
Ruby, the idea of changing fundamental types for specific programs
seemed notorious and reckless, what the Pythonistas used to snort
derisively about and call "Perlish," but I'm thinking it's actually a
very sensible approach. you shouldn't view Ruby the language as
fundamental - you should view it as a **template** for the language
you're actually going to use once you fully define the problem space
and your corresponding solution. like the Paul Graham idea about Lisp,
that you build the program down to the language and build the language
up to the program, except a lot more of the work is already done for
you when you start.

--
Giles Bowkett

Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com/
 
P

Phlip

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. :)

And when they invent Ruby keywords. (-;
 
T

Todd Burch

Darn. I was hoping to get a #to_binary added to Ruby with all the
#to_b talk.

Todd
 

Ask a Question

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.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top