Sth. wrong with File.file? (or with me)

ruby-talk
41

Hi,

···

In message "Re: Another scrach on head" on Sat, 30 Oct 2004 03:38:43 +0900, Jamis Buck <jgb3@email.byu.edu> writes:

No, I mispoke for the sake of simplification. nil and false _evaluate to
false_ in a boolean context, and everything else evaluates to _true_ in
a boolean context.

Ruby never get passed on telephone test.

"In Ruby, nil and false are false, but nil is not false, because false
does not equal to nil.."

              matz.

42

The main reason I brought up this issue is:
to make differentiation between "a value in boolean context" and "its
real value"

Example,
a = Foo.new
b = nil

a is *true* in boolean context but it is not really a TrueClass or true.
again, b is 'false' in a boolean context but it is not a FalseClass or
false.

thats why, I proposed to have

class Object
   def true?
      return ( (self == true) or (self === TrueClass) )
   end

   def false?
      return ( (self == false) or (self === FalseClass) )
   end
end

so.. again for the above examples:
puts "a is true in boolean context" if a
puts "a is really a *true*" if a.true?

puts "b is false in boolean context" if not b

Correction, please read
puts "b is false in boolean context" if b

···

On Thu, 2004-11-11 at 10:28, Mohammad Khan wrote:

puts "b is really *false*" if b.false?

if you find true? and false? is not readable or more complex to use, you
might like to write:
puts "a is really a *true*" if a == true
puts "b is really a *false*" if b == false

Thanks again,
Mohammad

On Thu, 2004-11-11 at 08:08, Robert Klemme wrote:
> "Jean-Hugues ROBERT" <jean_hugues_robert@yahoo.com> schrieb im Newsbeitrag
> news:6.0.1.1.0.20041111082218.040feec0@pop.mail.yahoo.com...
> > Hi,
> >
> > I think things should stay the way they are, here is
> > why.
> >
> > Things are a little complex about truthness/falseness.
> > One has to distinguish the "value" of an object from
> > its "truthness".
>
> I'm not sure whether I follow you here: an object *is* the value. There
> is no such thing as a value that is distinct from the object. An object
> is interpreted as in boolean contexts according to certain rules (false
> and nil => false, all others true); you could call this convention
> "truthness", yes.
>
> > Only nil and false are "false" from a "truthness"
> > perspective. All other objects are "true".
> >
> > For true? and false? to be somehow usefull, I first felt
> > that they should relate to the "truthness" of the
> > object, not its "value". That is very different from
> > nil? (it checks the value of the object, only The nil
> > object is nil?).
> >
> > This leads to:
> > class Object
> > def true? ; true ; end
> > def false? ; not true? ; end
> > end
> > class NilClass
> > def true? ; false ; end
> > end
> > class FalseClass
> > def true? ; false ; end
> > end
>
> You can simplify this to
>
> class Object
> def true?; self end
> def false?; not true? end
> end
>
> because it's the standard convention. Basically this adds one level of
> indirection (the method call).
>
> > Usage: 1 - Checking truthness
> > if some_thing.true? then
> > xxx
> > end
> > Usage: 2 - Checking value
> > if some_thing == true then
> > xxx
> > end
> >
> > On the other hand, one may consider that
> > checking the value is what matters most,
> > versus checking the truthness.
>
> I never felt the need for "some_thing == true". In which cases do you
> need this?
>
> > This leads to:
> > class Object
> > def true? ; false ; end
> > def false? ; false ; end
> > end
> > class TrueClass
> > def true? ; true ; end
> > end
> > class FalseClass
> > def false? ; true ; end
> > end
>
> You can simplify this, too:
>
> class Object
> def true?; TrueClass === self end
> def false?; FalseClass === self end
> end
>
> > Usage: 1 - Checking the truthness
> > if some_thing then
> > xxx
> > end
> > Usage: 2 - Checking the value
> > if some_thing.true? then
> > xxx
> > end
> >
> > Solution 2 (checking values) leads to
> > code that is slightly smaller (less characters).
> > Which is probably a good thing by itself.
> > However, I think that it is fairly unreadable.
>
> Yep. I find this quite irritating. When I see "if some_thing.true?
> then..." I'd expect the truthness of some_thing to be used, not the
> outcome of the test whether some_thing is actually the instance 'true'.
>
> > As a conclusion, I think that the status quo
> > is the best solution. Instead of a hard to
> > understand true?/false?, let's keep an explicit
> > xxx == true when value matters instead of
> > truthness.
>
> .... or "TrueClass === xxx" for that matter. Yes. Totally agree.
>
> > My 0.2 Euros.
>
> Now we got 0.22 EUR. :slight_smile:
>
> Kind regards
>
> robert

--

Everyone thinks of changing the world,
but no one thinks of changing himself.
                  - Leo Tolstoy

43

"Jean-Hugues ROBERT" <jean_hugues_robert@yahoo.com> schrieb im Newsbeitrag
news:6.0.1.1.0.20041111155014.01b91ff8@pop.mail.yahoo.com...

>"Jean-Hugues ROBERT" <jean_hugues_robert@yahoo.com> schrieb im

Newsbeitrag

>news:6.0.1.1.0.20041111082218.040feec0@pop.mail.yahoo.com...
>> Hi,
>>
>> I think things should stay the way they are, here is
>> why.
>>
>> Things are a little complex about truthness/falseness.
>> One has to distinguish the "value" of an object from
>> its "truthness".
>
>I'm not sure whether I follow you here: an object *is* the value.

There

>is no such thing as a value that is distinct from the object. An

object

>is interpreted as in boolean contexts according to certain rules (false
>and nil => false, all others true); you could call this convention
>"truthness", yes.

I don't agree. I don't think that an object IS a value.

An object is more than a value, it is made of:
  an identity
  a value (or state, or attributes, or ...)
  a behavior
Well... that's the way I learned OO.

Hm, I think we use a different notion of "value" here. I'd say that in
Ruby every value is an object - as opposed to Java for example, where
there is a distinction between POD's (int, char, long...) and objects.

Two objects can sometime have the same "value", this
is how == compares for equality.

#== and #equal? are completely independent of values: they form a
convention about when two instances are considered equivalent. For class
Object they have to share the same identity, i.e., every instance is
equivalent to itself only. For other classes (take structs as an example)
equivalence is defined recursively via equivalence of instance variables.

When I draw a line between "object" and "value" it is
about those special objects that compare equal to themselves
only. These are always immutable objects.

That last statement is not true:

class Foo
  attr_accessor :bar
end

Instances of Foo will only be equal to themselfs but they are not
immutable. This is because the inherit default behavior of Object.

Neither immutablility nor the definition of equivalence of Fixnums make
them special. What makes Fixnum special is the way those instances are
created and treated internally in the Ruby interpreter (which is merely an
implementation detail from the perspective of the language). But
otherwise they are completely normal - there is no such concept as in
Java, where you can have objects and POD's. Consider this:

class Fixnum
  def eql?(x) false end
  def ==(x) false end
end

1 == 1

=> true

1 == 2

=> false

class Fixnum
  def eql?(x) false end
  def ==(x) false end
end

=> nil

1 == 1

=> false

1 == 2

=> false

You can change the definition of Fixnum equivalence at your discretion.
Of course, many things would break if you do, but that's another story.

For example,
no two objects can have the same value 3, because 3
is an immutable integer. The same is true for true, false,
nil. On the other hand, two different strings can both
be valued "3". So, in my mind, 3 is a value, whereas
"3" is an object (whose initial value is "3"). To me
values are objects with some semantic restrictions.

Don't let yourself be fooled by the syntax: the char sequence '3' refers
an object that, in numerical calculations, behaves like the number 3 (i.e.
the mathematical concept). The char sequence '"3"' referns an object that
contains the given characters literally. Again, from the perspective of
the language Ruby, it's an implementation detail, that the object
accessible via '3' is always the same:

3.id

=> 7

3.id

=> 7

3.id

=> 7

3.id

=> 7

3.id

=> 7

while it's not for '"3"':

"3".id

=> 134992688

"3".id

=> 134985020

"3".id

=> 134977700

"3".id

=> 134972816

"3".id

=> 134969516

Of course it makes good sense to make the instance immutable so nobody can
change the state of the instance that the literal 3 refers. You can treat
the object accessible via '3' much the same like others although there are
some restrictions due to the implementation:

3.send( :+, 3 )

=> 6

3.to_s

=> "3"

3.class

=> Fixnum

>> Only nil and false are "false" from a "truthness"
>> perspective. All other objects are "true".
>>
>> For true? and false? to be somehow usefull, I first felt
>> that they should relate to the "truthness" of the
>> object, not its "value". That is very different from
>> nil? (it checks the value of the object, only The nil
>> object is nil?).
>>
>> This leads to:
>> class Object
>> def true? ; true ; end
>> def false? ; not true? ; end
>> end
>> class NilClass
>> def true? ; false ; end
>> end
>> class FalseClass
>> def true? ; false ; end
>> end
>
>You can simplify this to
>
>class Object
> def true?; self end
> def false?; not true? end
>end
>
>because it's the standard convention. Basically this adds one level of
>indirection (the method call).

But then: nil.true? => nil; I was expecting true, xxx? methods should
return a boolean I think.

That's not necessary in Ruby because all values can be treated
meaningfully in a boolean context (as opposed to Java for example).

>> Usage: 1 - Checking truthness
>> if some_thing.true? then
>> xxx
>> end
>> Usage: 2 - Checking value
>> if some_thing == true then
>> xxx
>> end
>>
>> On the other hand, one may consider that
>> checking the value is what matters most,
>> versus checking the truthness.
>
>I never felt the need for "some_thing == true". In which cases do you
>need this?

I don't. But the original poster may have a different answer I guess.

Yeah, probably.

>> This leads to:
>> class Object
>> def true? ; false ; end
>> def false? ; false ; end
>> end
>> class TrueClass
>> def true? ; true ; end
>> end
>> class FalseClass
>> def false? ; true ; end
>> end
>
>You can simplify this, too:
>
>class Object
> def true?; TrueClass === self end
> def false?; FalseClass === self end
>end

I suspect that this is less efficient. My
verbose code leverage the efficient method
dispatching of the interpreter (versus the
additional === test).

You're definitely right here.

>> Usage: 1 - Checking the truthness
>> if some_thing then
>> xxx
>> end
>> Usage: 2 - Checking the value
>> if some_thing.true? then
>> xxx
>> end
>>
>> Solution 2 (checking values) leads to
>> code that is slightly smaller (less characters).
>> Which is probably a good thing by itself.
>> However, I think that it is fairly unreadable.
>
>Yep. I find this quite irritating. When I see "if some_thing.true?
>then..." I'd expect the truthness of some_thing to be used, not the
>outcome of the test whether some_thing is actually the instance 'true'.
>
>> As a conclusion, I think that the status quo
>> is the best solution. Instead of a hard to
>> understand true?/false?, let's keep an explicit
>> xxx == true when value matters instead of
>> truthness.
>
>.... or "TrueClass === xxx" for that matter. Yes. Totally agree.
>
>> My 0.2 Euros.
>
>Now we got 0.22 EUR. :slight_smile:

You make my day :wink:

Should I open up a savings account? :slight_smile:

Unfortunately I have to go now, otherwise my answer would have been more
verbose, I guess. But we can continue this tomorrow. :slight_smile:

Kind regards

    robert

···

At 22:08 11/11/2004 +0900, you wrote:

44

The main reason I brought up this issue is: to make
differentiation between "a value in boolean context" and "its real
value"

Why? This is the ultimate question that I don't think has been
answered at all. Why is #true? and #false superior to explicit
tests? Note that I'm not referring to the alternative directions
inspired by your post (e.g., #if_true and #if_false), but your
suggestion that "foo.true?" is better than "foo == true".

class Object
  def true?
    return ( (self == true) or (self === TrueClass) )
  end

  def false?
    return ( (self == false) or (self === FalseClass) )
  end
end

This is improperly written. +true+, +false+, and +nil+ are the only
possible values of TrueClass, FalseClass, and NilClass,
respectively. Thus, self == true and TrueClass === self (note the
inversion of parameters on the call to #===) are the same test. You
can more efficiently write what you want as:

  class Object
    def true?
      false
    end

    def false?
      false
    end
  end

  class TrueClass
    def true?
      true
    end
  end

  class FalseClass
    def false?
      true
    end
  end

(This is, more or less, how nil? is written. Object#nil? returns
false; NilClass#nil? returns true.)

so.. again for the above examples:
puts "a is true in boolean context" if a
puts "a is really a *true*" if a.true?

Why is this better than "if a == true"

puts "b is false in boolean context" if not b

Try "unless b".

-austin

···

On Fri, 12 Nov 2004 00:28:35 +0900, Mohammad Khan <mkhan@lextranet.com> wrote:
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

45

Hi --

> No, I mispoke for the sake of simplification. nil and false _evaluate to
> false_ in a boolean context, and everything else evaluates to _true_ in
> a boolean context.
>
> Thus
>
> puts "here" if false
> puts "there" if nil
>
> would print nothing, whereas
>
> puts "here" if true
> puts "there" if 5
> puts "everywhere" if 1 && Object.new && :foobar
>
> would print
>
> here
> there
> everywhere
>
> Hope that is clearer.
>
> - Jamis

In other words

a = Whatever.new

puts "a is nil" if a.nil?
puts "a is neither nil, nor false" if a
puts "a is true" if a == true
puts "a is false" if a == false
puts "a is nil again!" if a == nil

You could also say

  puts "a is true" if a
  puts "a is false" if a.nil?

in the Boolean sense of true/false. Ruby provides the constants TRUE
and FALSE, for the respective objects; this might be a good way to
write your example (and my additions):

puts "a is nil" if a.nil?
puts "a is neither nil,
     nor false, nor FALSE" if a
puts "a is TRUE" if a == TRUE
puts "a is true" if a
puts "a is FALSE" if a == FALSE
puts "a is false" if not a
puts "a is nil again!" if a == nil
puts "a is false" if a.nil?

Here, I'm using 'true/false' to mean Boolean true/false, and
TRUE/FALSE to mean the objects.

David

···

On Sat, 30 Oct 2004, Mohammad Khan wrote:

On Fri, 2004-10-29 at 14:38, Jamis Buck wrote:

--
David A. Black
dblack@wobblini.net

46

In article <1099108973.918346.12359.nullmailer@x31.priv.netlab.jp>, Yukihiro
Matsumoto wrote:

Hi,

No, I mispoke for the sake of simplification. nil and false _evaluate to
false_ in a boolean context, and everything else evaluates to _true_ in
a boolean context.

Ruby never get passed on telephone test.

"In Ruby, nil and false are false, but nil is not false, because false
does not equal to nil.."

            matz.

This reminds me of some code written by a (normally sensible) co-worker.
It went something like
   
   unless foo
     ...
   else
     ...
   end

I like to call the second condition "else if not unless foo."

···

In message "Re: Another scrach on head" > on Sat, 30 Oct 2004 03:38:43 +0900, Jamis Buck <jgb3@email.byu.edu> writes:

47

Hi Matz,

Thanks for your reply.
What about 'true'?

My point was,

a = Whatever.new # other than NilClass or FalseClass

if a
   # block 1
end

if a == true
   # block 2
end

block 1 and block 2 will be executed only when a.class is TrueClass.

I guess,
in #1
other than nil and false, everything is considering as true.
and in #2
we are doing equality test with 'true' that will return a boolean.

If, I am right, shouldn't we have two have method 'false?' and 'true?' that
will return boolean based on equality test
with false and true respectively just like nil?.

I am sorry, If I am misunderstanding something or requesting something that shouldn't be.

regards,
Mohammad

···

On Sat, 2004-10-30 at 00:03, Yukihiro Matsumoto wrote:

Hi,

In message "Re: Another scrach on head" > on Sat, 30 Oct 2004 03:38:43 +0900, Jamis Buck <jgb3@email.byu.edu> writes:

>No, I mispoke for the sake of simplification. nil and false _evaluate to
>false_ in a boolean context, and everything else evaluates to _true_ in
>a boolean context.

Ruby never get passed on telephone test.

"In Ruby, nil and false are false, but nil is not false, because false
does not equal to nil.."

              matz.

48

Yukihiro Matsumoto wrote:

Ruby never get passed on telephone test.

"In Ruby, nil and false are false, but nil is not false, because false
does not equal to nil.."

"In Ruby, nil and false are false values, but nil is not equivalent to false, because false does not equal to nil.."

:wink:

49

Hi there,

So. What is a value ? What is an object ? What are the
benefits in distinguishing ?

I feel like we should not stick to the implementation
level to understand the difference, because, in Ruby,
everything (almost) is an object.

My understanding is that the value of an object is
something abstract and immutable that captures the
current state of the object.

I feel like this is a well agreed on notion,
for example within RPC mechanisms when the notion
of "by value" versus "by reference" is used.

When something is passed "by value", it is very clear
that the object whose value was passed is not going
to be modified by the invoked procedure.

Now, some class instances don't require an explicit
choice: "by value" or "by reference", because it
does not matter. This is the case for all instances
of the Integer class, as well as for true, false,
nil and so on. I tend to think of objects of such
classes as "values".

The Ruby String class is an interesting example.
A beginner frequent error is to forget that a Ruby
String object is mutable (i.e. is not a value).
I believe that in Java they distinguish things:
  String : Immutable
  StringBuf : Mutable

To get back to the original post, the issue is
whether true? and false? should test the "value"
of the object *or* its semantic in the context
of a boolean expression (its "truth ness"). If
you know Ruby enough, you understand that false?
makes sense only if it tests the value. If you
are a beginner, you probably get confused. On
the other hand the current "if xx == false then"
should be readable enough for a beginner to
understand that the condition is not met if
xx is nil.

Yours,

    JeanHuguesRobert

EOM

···

At 01:18 12/11/2004 +0900, you wrote:

"Jean-Hugues ROBERT" <jean_hugues_robert@yahoo.com> schrieb im Newsbeitrag
news:6.0.1.1.0.20041111155014.01b91ff8@pop.mail.yahoo.com...

At 22:08 11/11/2004 +0900, you wrote:

>"Jean-Hugues ROBERT" <jean_hugues_robert@yahoo.com> schrieb im

Newsbeitrag

>news:6.0.1.1.0.20041111082218.040feec0@pop.mail.yahoo.com...
>> Hi,
>>
>> I think things should stay the way they are, here is
>> why.
>>
>> Things are a little complex about truthness/falseness.
>> One has to distinguish the "value" of an object from
>> its "truthness".
>
>I'm not sure whether I follow you here: an object *is* the value.

There

>is no such thing as a value that is distinct from the object. An

object

>is interpreted as in boolean contexts according to certain rules (false
>and nil => false, all others true); you could call this convention
>"truthness", yes.

I don't agree. I don't think that an object IS a value.

An object is more than a value, it is made of:
  an identity
  a value (or state, or attributes, or ...)
  a behavior
Well... that's the way I learned OO.

Hm, I think we use a different notion of "value" here. I'd say that in
Ruby every value is an object - as opposed to Java for example, where
there is a distinction between POD's (int, char, long...) and objects.

Two objects can sometime have the same "value", this
is how == compares for equality.

#== and #equal? are completely independent of values: they form a
convention about when two instances are considered equivalent. For class
Object they have to share the same identity, i.e., every instance is
equivalent to itself only. For other classes (take structs as an example)
equivalence is defined recursively via equivalence of instance variables.

When I draw a line between "object" and "value" it is
about those special objects that compare equal to themselves
only. These are always immutable objects.

That last statement is not true:

class Foo
attr_accessor :bar
end

Instances of Foo will only be equal to themselfs but they are not
immutable. This is because the inherit default behavior of Object.

Neither immutablility nor the definition of equivalence of Fixnums make
them special. What makes Fixnum special is the way those instances are
created and treated internally in the Ruby interpreter (which is merely an
implementation detail from the perspective of the language). But
otherwise they are completely normal - there is no such concept as in
Java, where you can have objects and POD's. Consider this:

class Fixnum
def eql?(x) false end
def ==(x) false end
end

1 == 1

=> true

1 == 2

=> false

class Fixnum
  def eql?(x) false end
  def ==(x) false end
end

=> nil

1 == 1

=> false

1 == 2

=> false

You can change the definition of Fixnum equivalence at your discretion.
Of course, many things would break if you do, but that's another story.

For example,
no two objects can have the same value 3, because 3
is an immutable integer. The same is true for true, false,
nil. On the other hand, two different strings can both
be valued "3". So, in my mind, 3 is a value, whereas
"3" is an object (whose initial value is "3"). To me
values are objects with some semantic restrictions.

Don't let yourself be fooled by the syntax: the char sequence '3' refers
an object that, in numerical calculations, behaves like the number 3 (i.e.
the mathematical concept). The char sequence '"3"' referns an object that
contains the given characters literally. Again, from the perspective of
the language Ruby, it's an implementation detail, that the object
accessible via '3' is always the same:

3.id

=> 7

3.id

=> 7

3.id

=> 7

3.id

=> 7

3.id

=> 7

while it's not for '"3"':

"3".id

=> 134992688

"3".id

=> 134985020

"3".id

=> 134977700

"3".id

=> 134972816

"3".id

=> 134969516

Of course it makes good sense to make the instance immutable so nobody can
change the state of the instance that the literal 3 refers. You can treat
the object accessible via '3' much the same like others although there are
some restrictions due to the implementation:

3.send( :+, 3 )

=> 6

3.to_s

=> "3"

3.class

=> Fixnum

>> Only nil and false are "false" from a "truthness"
>> perspective. All other objects are "true".
>>
>> For true? and false? to be somehow usefull, I first felt
>> that they should relate to the "truthness" of the
>> object, not its "value". That is very different from
>> nil? (it checks the value of the object, only The nil
>> object is nil?).
>>
>> This leads to:
>> class Object
>> def true? ; true ; end
>> def false? ; not true? ; end
>> end
>> class NilClass
>> def true? ; false ; end
>> end
>> class FalseClass
>> def true? ; false ; end
>> end
>
>You can simplify this to
>
>class Object
> def true?; self end
> def false?; not true? end
>end
>
>because it's the standard convention. Basically this adds one level of
>indirection (the method call).

But then: nil.true? => nil; I was expecting true, xxx? methods should
return a boolean I think.

That's not necessary in Ruby because all values can be treated
meaningfully in a boolean context (as opposed to Java for example).

>> Usage: 1 - Checking truthness
>> if some_thing.true? then
>> xxx
>> end
>> Usage: 2 - Checking value
>> if some_thing == true then
>> xxx
>> end
>>
>> On the other hand, one may consider that
>> checking the value is what matters most,
>> versus checking the truthness.
>
>I never felt the need for "some_thing == true". In which cases do you
>need this?

I don't. But the original poster may have a different answer I guess.

Yeah, probably.

>> This leads to:
>> class Object
>> def true? ; false ; end
>> def false? ; false ; end
>> end
>> class TrueClass
>> def true? ; true ; end
>> end
>> class FalseClass
>> def false? ; true ; end
>> end
>
>You can simplify this, too:
>
>class Object
> def true?; TrueClass === self end
> def false?; FalseClass === self end
>end

I suspect that this is less efficient. My
verbose code leverage the efficient method
dispatching of the interpreter (versus the
additional === test).

You're definitely right here.

>> Usage: 1 - Checking the truthness
>> if some_thing then
>> xxx
>> end
>> Usage: 2 - Checking the value
>> if some_thing.true? then
>> xxx
>> end
>>
>> Solution 2 (checking values) leads to
>> code that is slightly smaller (less characters).
>> Which is probably a good thing by itself.
>> However, I think that it is fairly unreadable.
>
>Yep. I find this quite irritating. When I see "if some_thing.true?
>then..." I'd expect the truthness of some_thing to be used, not the
>outcome of the test whether some_thing is actually the instance 'true'.
>
>> As a conclusion, I think that the status quo
>> is the best solution. Instead of a hard to
>> understand true?/false?, let's keep an explicit
>> xxx == true when value matters instead of
>> truthness.
>
>.... or "TrueClass === xxx" for that matter. Yes. Totally agree.
>
>> My 0.2 Euros.
>
>Now we got 0.22 EUR. :slight_smile:

You make my day :wink:

Should I open up a savings account? :slight_smile:

Unfortunately I have to go now, otherwise my answer would have been more
verbose, I guess. But we can continue this tomorrow. :slight_smile:

Kind regards

   robert

-------------------------------------------------------------------------
Web: http://hdl.handle.net/1030.37/1.1
Phone: +33 (0) 4 92 27 74 17

50

> The main reason I brought up this issue is: to make
> differentiation between "a value in boolean context" and "its real
> value"

Why? This is the ultimate question that I don't think has been
answered at all. Why is #true? and #false superior to explicit
tests? Note that I'm not referring to the alternative directions
inspired by your post (e.g., #if_true and #if_false), but your
suggestion that "foo.true?" is better than "foo == true".

> class Object
> def true?
> return ( (self == true) or (self === TrueClass) )
> end
>
> def false?
> return ( (self == false) or (self === FalseClass) )
> end
> end

This is improperly written. +true+, +false+, and +nil+ are the only
possible values of TrueClass, FalseClass, and NilClass,

Yes, I wrote it improperly, sorry about that.

class Object
    def true?
        return self == true
    end

    def false?
        return self == false
    end
end

respectively. Thus, self == true and TrueClass === self (note the
inversion of parameters on the call to #===) are the same test. You
can more efficiently write what you want as:

  class Object
    def true?
      false
    end

    def false?
      false
    end
  end

You might noticed from my previous posting, the reason to I want to have
#true? and #false?

Example:
a = true
b = false

using my 'class Object'
a.true? -> true
b.false? -> true

using your 'class Object'
a.true? -> false
b.false? -> false
which are wrong according to my proposed #true? and #false?

  class TrueClass
    def true?
      true
    end
  end

  class FalseClass
    def false?
      true
    end
  end

(This is, more or less, how nil? is written. Object#nil? returns
false; NilClass#nil? returns true.)

> so.. again for the above examples:
> puts "a is true in boolean context" if a
> puts "a is really a *true*" if a.true?

Why is this better than "if a == true"

I think, its a personal taste.
I like "a.nil?" more than "a == nil"
same way, I like a.true? than a == true
when I consider 'a' in boolean context.. i write . .. " if a"
when I need to make sure that 'a' is really a 'true'.. I write a.true?,
you might write it a == true.

"We live in a free world"
:wink:

···

On Thu, 2004-11-11 at 14:50, Austin Ziegler wrote:

On Fri, 12 Nov 2004 00:28:35 +0900, Mohammad Khan > <mkhan@lextranet.com> wrote:

--
Mohammad

> puts "b is false in boolean context" if not b

Try "unless b".

-austin
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

51

>
> In other words
>
> a = Whatever.new
>
> puts "a is nil" if a.nil?
> puts "a is neither nil, nor false" if a
> puts "a is true" if a == true
> puts "a is false" if a == false
> puts "a is nil again!" if a == nil

You could also say

  puts "a is true" if a

David,

I don't agree at this point, I would like to say

puts "a is neither nil, nor false, nor FALSE" if a
puts "a is true" if a == true

I consider nil, false and true as three different entity.
I don't need to show you irb screen output to illustrate it.

Thanks,
Mohammad

···

  puts "a is false" if a.nil?

in the Boolean sense of true/false. Ruby provides the constants TRUE
and FALSE, for the respective objects; this might be a good way to
write your example (and my additions):

puts "a is nil" if a.nil?
puts "a is neither nil,
     nor false, nor FALSE" if a
puts "a is TRUE" if a == TRUE
puts "a is true" if a
puts "a is FALSE" if a == FALSE
puts "a is false" if not a
puts "a is nil again!" if a == nil
puts "a is false" if a.nil?

Here, I'm using 'true/false' to mean Boolean true/false, and
TRUE/FALSE to mean the objects.

David

--
Mohammad Khan <mkhan@lextranet.com>
Legal Computer Solutions, Inc.

52

Hi --

> Hi,
>
>
> >No, I mispoke for the sake of simplification. nil and false _evaluate to
> >false_ in a boolean context, and everything else evaluates to _true_ in
> >a boolean context.
>
> Ruby never get passed on telephone test.
>
> "In Ruby, nil and false are false, but nil is not false, because false
> does not equal to nil.."
>
> matz.

Hi Matz,

Thanks for your reply.
What about 'true'?

My point was,

a = Whatever.new # other than NilClass or FalseClass

if a
   # block 1
end

if a == true
   # block 2
end

block 1 and block 2 will be executed only when a.class is TrueClass.

I guess,
in #1
other than nil and false, everything is considering as true.
and in #2
we are doing equality test with 'true' that will return a boolean.

If, I am right, shouldn't we have two have method 'false?' and 'true?' that
will return boolean based on equality test
with false and true respectively just like nil?.

I don't think the names are very clear. This would be weird, to me:

   a = "hi"
   puts "hello" if a.true? # no output

I suppose it's symmetrical with .nil? and .zero? (i.e., "is this the
actual object [nil or zero]?"), but in the case of true and false I
find my mind defaulting to the Boolean state, rather than the object.

#false? might be useful to avoid lengthier tests distinguishing among
various permutations of falsehood. I can't see too many likely uses
for #true?

David

···

On Tue, 2 Nov 2004, Mohammad Khan wrote:

On Sat, 2004-10-30 at 00:03, Yukihiro Matsumoto wrote:
> In message "Re: Another scrach on head" > > on Sat, 30 Oct 2004 03:38:43 +0900, Jamis Buck <jgb3@email.byu.edu> writes:

--
David A. Black
dblack@wobblini.net

53

and perhaps also

   Object#bool?

     def bool?
       true? or false?
     end

-a

···

On Tue, 2 Nov 2004, Mohammad Khan wrote:

If, I am right, shouldn't we have two have method 'false?' and 'true?'
that will return boolean based on equality test with false and true
respectively just like nil?.

--

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
When you do something, you should burn yourself completely, like a good
bonfire, leaving no trace of yourself. --Shunryu Suzuki

===============================================================================

54

Mohammad Khan wrote:

Hi,

No, I mispoke for the sake of simplification. nil and false _evaluate to false_ in a boolean context, and everything else evaluates to _true_ in a boolean context.

Ruby never get passed on telephone test.

"In Ruby, nil and false are false, but nil is not false, because false
does not equal to nil.."

            matz.
   
Hi Matz,

Thanks for your reply.
What about 'true'?

My point was,

a = Whatever.new # other than NilClass or FalseClass

if a
  # block 1
end

if a == true
  # block 2
end

block 1 and block 2 will be executed only when a.class is TrueClass.

This is not true, block 1 will execute if *a* is anything but nil or false.

a = "a string"
puts "a evaluates to true" if a

or

if a then
    puts "a evalutes to true"
end

Zach

···

On Sat, 2004-10-30 at 00:03, Yukihiro Matsumoto wrote:

In message "Re: Another scrach on head" >> on Sat, 30 Oct 2004 03:38:43 +0900, Jamis Buck <jgb3@email.byu.edu> writes:

55

Well I have written true? and false? methods in the past. Forgetting
the best implementation at the moment I use it because I find things
like:

if a.nil?.false?
   ....
end

more readable than

if not a.nil?
....
end

56

respectively. Thus, self == true and TrueClass === self (note the
inversion of parameters on the call to #===) are the same test.
You can more efficiently write what you want as:

class Object
  def true?
    false
  end

  def false?
    false
  end
end

You might noticed from my previous posting, the reason to I want
to have #true? and #false?

No, I didn't. Not anything convincing, at any rate. It seemed to
boil down to "I don't think that a == b is sufficiently OO", which
is certainly not a good reason, IMO. Why do you not like "a ==
true"?

Example:
a = true
b = false

using my 'class Object'
a.true? -> true
b.false? -> true

using your 'class Object'
a.true? -> false
b.false? -> false
which are wrong according to my proposed #true? and #false?

Not if you actually did what I said, which was *NOT* just adding
#true? and #false? to Object. Look again; it does what you want and
it does it cleaner than your == test.

so.. again for the above examples: puts "a is true in boolean
context" if a puts "a is really a *true*" if a.true?

Why is this better than "if a == true"

I think, its a personal taste.

That rather goes against (IMO) sensible program design, especially
if you're going to work with others.

I like "a.nil?" more than "a == nil"
same way, I like a.true? than a == true

"We live in a free world"

Yes, we do. I don't think, however, that the Ruby world needs #true?
and #false?

-austin

···

On Fri, 12 Nov 2004 05:41:50 +0900, Mohammad Khan <mkhan@lextranet.com> wrote:

On Thu, 2004-11-11 at 14:50, Austin Ziegler wrote:

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

57

David,

I don't agree at this point, I would like to say

puts "a is neither nil, nor false, nor FALSE" if a
puts "a is true" if a == true

I consider nil, false and true as three different entity.
I don't need to show you irb screen output to illustrate it.

Thanks,
Mohammad

Correcting myself,
if it is (not nil and not false and not FALSE)
only remaining state is .. true or TRUE !!

:stuck_out_tongue:

Mohammad

···

> puts "a is false" if a.nil?
>
> in the Boolean sense of true/false. Ruby provides the constants TRUE
> and FALSE, for the respective objects; this might be a good way to
> write your example (and my additions):
>
> puts "a is nil" if a.nil?
> puts "a is neither nil,
> nor false, nor FALSE" if a
> puts "a is TRUE" if a == TRUE
> puts "a is true" if a
> puts "a is FALSE" if a == FALSE
> puts "a is false" if not a
> puts "a is nil again!" if a == nil
> puts "a is false" if a.nil?
>
> Here, I'm using 'true/false' to mean Boolean true/false, and
> TRUE/FALSE to mean the objects.
>
>
> David

--
Mohammad Khan <mkhan@lextranet.com>
Legal Computer Solutions, Inc.

58

I'm not sure this is a good consideration. Coming from an SQL
background, it's easy to do, but I think that Matz has this right. A
nil value is something that's unset.

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

-austin

···

On Sat, 30 Oct 2004 06:24:49 +0900, Mohammad Khan <mkhan@lextranet.com> wrote:

I consider nil, false and true as three different entity.
I don't need to show you irb screen output to illustrate it.

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

59

i'd really like a #true?

   yaml = <<-txt
     options:
       verbose : true # or maybe 4
   txt

   config = YAML::load yaml

   options = config['options']

   if options['verbose'].true?
     @verbosity = 4
   else
     @verbosity = Integer options['verbose']
   end

now i use

   if TrueClass === options['verbose']
     @verbosity = 4
   else
     @verbosity = Integer options['verbose']
   end

which is kind of ugly. espcially where i care if it true OR false and end
doing

···

On Tue, 2 Nov 2004, David A. Black wrote:

#false? might be useful to avoid lengthier tests distinguishing among
various permutations of falsehood. I can't see too many likely uses
for #true?

#
# foobar can be a bool or a number
#
   if [TrueClass, FalseClass].include? options['foobar'].class
     @foobar = options['foobar']
   else
     @foobar = Integer options['foobar']
   end

yuk!

cheers.

-a
--

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
When you do something, you should burn yourself completely, like a good
bonfire, leaving no trace of yourself. --Shunryu Suzuki

===============================================================================

60

>
>a = Whatever.new # other than NilClass or FalseClass
>
>if a
> # block 1
>end
>
>if a == true
> # block 2
>end
>
>block 1 and block 2 will be executed only when a.class is TrueClass.
>
>
>
This is not true, block 1 will execute if *a* is anything but nil or false.

a = "a string"
puts "a evaluates to true" if a

or

if a then
    puts "a evalutes to true"
end

Zach

output will be:
a evaluates to true
a evalutes to true

···

--
Mohammad