Another scrach on head

ruby-talk
1

//I still don't see a reason for #true? and #false?.

it's a language problem. ruby caters english and sometimes the language does
not fall immediately into ones (non-english) ears... Thus the op was asking
if he could be more explicit+...

consider:

a = (1 > 0)
if a
   block
end

At a first glance (assumming sans k on progg lang), one has to know
semantics of if. And here, one realizes that block executes if a is true.

now consider:

if a.true?
   block
end

Surely, one can deduce that block will execute if a is true.

and

if a.false?
   block
end

Surely, one can deduce that block will execute if a is false. One does not
need to bend mind just to say "if not a". Why would one want to say "not
true" when he can say "false"?

And besides,

"if a" does not look o-o to me (only).
"if a.is_a" or "if a.kind_of" looks o-o.

also

irb(main):010:0> p a.methods
["send", "&", "object_id", "singleton_methods", "__send__", "equal?",
"taint", "frozen?", "instance_variab
le_get", "kind_of?", "to_a", "instance_eval", "type", "protected_methods",
"extend", "|", "eql?", "instanc
e_variable_set", "hash", "is_a?", "to_s", "class", "tainted?",
"private_methods", "^", "untaint", "id", "i
nspect", "==", "===", "clone", "public_methods", "respond_to?", "display",
"freeze", "__id__", "=~", "meth
ods", "method", "nil?", "dup", "instance_variables", "instance_of?"]

a is really an object.

so "if a" is asking like "is a an object" ??

Btw, in our local dialect, we do not have an "if a" counterpart, so you can
understand our slight predicament :expressionless:

kind regards -botp

2

//I still don't see a reason for #true? and #false?.

it's a language problem. ruby caters english and sometimes the
language does not fall immediately into ones (non-english) ears...
Thus the op was asking if he could be more explicit+...

consider:

a = (1 > 0)
if a
  block
end

At a first glance (assumming sans k on progg lang), one has to
know semantics of if. And here, one realizes that block executes
if a is true.

Mmm. I don't think changing that to if a.true? will help readability
in the least, because a.true? only applies if it is literally the
value +true+ (e.g., the instance of TrueClass). The same for
a.false?.

As far as "if a.false?" vs "if not a", this is why Ruby has
"unless", e.g., "unless a".

so "if a" is asking like "is a an object" ??

No, "if a" asks "is 'a' a non-nil-or-false value". "unless a" asks
"is 'a' a nil-or-false value".

-austin

···

On Sat, 30 Oct 2004 14:47:34 +0900, Peña, Botp <botp@delmonte-phil.com> wrote:
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca
: as of this email, I have [ 5 ] Gmail invitations

3

this will return a boolean, so it doesn't fit in my example.
try, a = Foo.new and consider your examples.
You will know, what I mean.

···

On Sat, 2004-10-30 at 01:47, "Peña, Botp" wrote:

//I still don't see a reason for #true? and #false?.

it's a language problem. ruby caters english and sometimes the language does
not fall immediately into ones (non-english) ears... Thus the op was asking
if he could be more explicit+...

consider:

a = (1 > 0)

--
Mohammad

if a
   block
end

At a first glance (assumming sans k on progg lang), one has to know
semantics of if. And here, one realizes that block executes if a is true.

now consider:

if a.true?
   block
end

Surely, one can deduce that block will execute if a is true.

and

if a.false?
   block
end

Surely, one can deduce that block will execute if a is false. One does not
need to bend mind just to say "if not a". Why would one want to say "not
true" when he can say "false"?

And besides,

"if a" does not look o-o to me (only).
"if a.is_a" or "if a.kind_of" looks o-o.

4

No, I'm sorry, I *don't* know what you mean. Foo.new is a true value.

I'm not seeing the purpose of this. Really.

-austin

···

On Tue, 2 Nov 2004 03:29:06 +0900, Mohammad Khan <mkhan@lextranet.com> wrote:

On Sat, 2004-10-30 at 01:47, "Peña, Botp" wrote:
> //I still don't see a reason for #true? and #false?.
>
> it's a language problem. ruby caters english and sometimes the language does
> not fall immediately into ones (non-english) ears... Thus the op was asking
> if he could be more explicit+...
>
> consider:
>
> a = (1 > 0)

this will return a boolean, so it doesn't fit in my example.
try, a = Foo.new and consider your examples.
You will know, what I mean.

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca
: as of this email, I have [ 5 ] Gmail invitations

5

Foo.new is not a true value,
Foo.new is *considered* as true value
If it is true value,
the following boolean expression should return true:

Foo.new == true

···

On Mon, 2004-11-01 at 14:55, Austin Ziegler wrote:

On Tue, 2 Nov 2004 03:29:06 +0900, Mohammad Khan <mkhan@lextranet.com> wrote:
> On Sat, 2004-10-30 at 01:47, "Peña, Botp" wrote:
> > //I still don't see a reason for #true? and #false?.
> >
> > it's a language problem. ruby caters english and sometimes the language does
> > not fall immediately into ones (non-english) ears... Thus the op was asking
> > if he could be more explicit+...
> >
> > consider:
> >
> > a = (1 > 0)
>
> this will return a boolean, so it doesn't fit in my example.
> try, a = Foo.new and consider your examples.
> You will know, what I mean.

No, I'm sorry, I *don't* know what you mean. Foo.new is a true value.

--
Mohammad

I'm not seeing the purpose of this. Really.

-austin

6

In some other language, perhaps, but not in Ruby. IMO, the decision
ultimately being left to Matz. That which is not false or nil is true.

-austin

···

On Tue, 2 Nov 2004 05:01:17 +0900, Mohammad Khan <mkhan@lextranet.com> wrote:

> No, I'm sorry, I *don't* know what you mean. Foo.new is a true value.
Foo.new is not a true value,
Foo.new is *considered* as true value
If it is true value,
the following boolean expression should return true:

Foo.new == true

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca
: as of this email, I have [ 5 ] Gmail invitations