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

ruby-talk
21

Mohammad Khan wrote:
[snip]

# 2
if (a)
  block # 2
end

[snip]

# 6
if (not a.nil?)
  block # 6
end

So, isn't #6 more logical than #2.
Didn't we wanted to mean #6 when we wrote #2

By definition (in Ruby), nil and false are false, and _everything else_ is true. Its an axiom in Ruby. Just as, in C, 0 is false and all other integers are true.

- Jamis

···

--
Jamis Buck
jgb3@email.byu.edu
http://www.jamisbuck.org/jamis

22

Mohammad Khan wrote:

if (expression)
  block # 1
end

block # 1 would be executed if expression is true.

Watch this,
a = 5

# 2
if (a)
block # 2
end

# 3
if (true)
block # 3
end

# 4
if (a == true)
block # 4
end

# 5
if (a.class == TrueClass)
block # 5
end

# 6
if (not a.nil?)
block # 6
end

Ofcource, block # 4 and #5 would not execute.
Why would block # 2 ?

Everything in ruby except for false and nil return true in a boolean expression.

So, isn't #6 more logical than #2.

#2 is more reader friendly at a quick glance and it is faster to type then #6.

Didn't we wanted to mean #6 when we wrote #2

#2 and #6 will always evaluate to the same result.

Zach

23

The point Austin was making was, if nil? was removed why would you need
to write

That's why I wanted to have true? and false? method.

a == nil or a.class == NilClass

rather than just

a == nil

that make sense, if a = nil, a.class is NilClass

···

On Fri, 2004-10-29 at 13:57, mark sparshatt wrote:

Likewise, why do you need to write

a == true or a.class == TrueClass

rather than

a == true

?

--
Mark Sparshatt

24

Cool, that'll work.

T.

···

On Friday 29 October 2004 12:28 pm, Mohammad Khan wrote:

In my mind, I had this:

class Object
    def true?
        return self == true ? true : false
    end

    def false?
        return self == false ? true : false
    end
end

25

I'm still skeptical about the usefulness of this, but I think the best
implementation would be:

def true.true?
  true
end

def false.false?
  false
end

I'm not actually sure, though, that these wouldn't belong in TrueClass
and FalseClass.

Bill

···

On Sat, 30 Oct 2004 01:28:39 +0900, Mohammad Khan <mkhan@lextranet.com> wrote:

On Fri, 2004-10-29 at 12:01, trans. (T. Onoma) wrote:
> On Friday 29 October 2004 11:55 am, Mohammad Khan wrote:
> > On Fri, 2004-10-29 at 11:48, Bill Atkins wrote:
> > > Well, all Objects must be nil or non-nil, but the idea of true/false
> > > doesn't apply to all objects.
> >
> > I agree with you on this point.
> >
> > I would ask,
> > If I would like to have true? and false?
> > what would be best class to put in?
>
> But it must be responded to by all classes.
>
> # true?&false?.rb
> # As suggested by Mohammad Khan
>
> class Object
> def true? ; false ; end
> def false? ; false ; end
> end
>
In my mind, I had this:

class Object
    def true?
        return self == true ? true : false
    end

    def false?
        return self == false ? true : false
    end
end

irb(main):009:0> n = nil
=> nil
irb(main):010:0> n.nil?
=> true
irb(main):011:0> n.true?
=> false
irb(main):012:0> n.false?
=> false
irb(main):013:0> t = true
=> true
irb(main):015:0> t.true?
=> true
irb(main):016:0> t.false?
=> false
irb(main):017:0> f = false
=> false
irb(main):018:0> f.nil?
=> false
irb(main):019:0> f.true?
=> false
irb(main):020:0> f.false?
=> true

> class TrueClass
> def true? ; true ; end
> end
>
> class FalseClass
> def false? ; true ; end
> end
>
> Is this what you had in mind?
>
> T.
--
Mohammad Khan <mkhan@lextranet.com>
Legal Computer Solutions, Inc.

26

You mean:

  if (not (a.nil? or a.false?))

much easier

  if a

T.

···

On Friday 29 October 2004 02:07 pm, Zach Dennis wrote:

># 6
>if (not a.nil?)
> block # 6
>end

27

Thanks, for clarify this. My appology, I didn't know that !

···

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

By definition (in Ruby), nil and false are false, and _everything else_
is true. Its an axiom in Ruby. Just as, in C, 0 is false and all other
integers are true.

--
Mohammad

28

Hi --

># 2
>if (a)
> block # 2
>end
>
># 6
>if (not a.nil?)
> block # 6
>end
>
#2 and #6 will always evaluate to the same result.

Almost always :slight_smile:

  irb(main):004:0> a = false
  irb(main):005:0> if (a); puts 2; end
  => nil
  irb(main):006:0> if (not a.nil?); puts 6; end
  6
  => nil

David

···

On Sat, 30 Oct 2004, Zach Dennis wrote:

--
David A. Black
dblack@wobblini.net

29

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

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

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

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.

My 0.2 Euros.

Yours,

    JeanHuguesRobert

···

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

30

yes, they will work.
But question is, should they place in Object?

···

On Fri, 2004-10-29 at 12:34, trans. (T. Onoma) wrote:

On Friday 29 October 2004 12:28 pm, Mohammad Khan wrote:
> In my mind, I had this:
>
> class Object
> def true?
> return self == true ? true : false
> end
>
> def false?
> return self == false ? true : false
> end
> end

Cool, that'll work.

T.

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

31

Wait a minute,
you are trying to say,
nil and false are false.
so we should have
nil == false -> true

···

On Fri, 2004-10-29 at 14:16, Mohammad Khan wrote:

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

> By definition (in Ruby), nil and false are false, and _everything else_
> is true. Its an axiom in Ruby. Just as, in C, 0 is false and all other
> integers are true.

Thanks, for clarify this. My appology, I didn't know that !

--
Mohammad

32

Hi --

> ># 2
> >if (a)
> > block # 2
> >end
> >
> ># 6
> >if (not a.nil?)
> > block # 6
> >end
> >
> #2 and #6 will always evaluate to the same result.

Almost always :slight_smile:

  irb(main):004:0> a = false
  irb(main):005:0> if (a); puts 2; end
  => nil
  irb(main):006:0> if (not a.nil?); puts 6; end
  6
  => nil

Exactly, thats what I wanted to illustrate.
nil is not false.

what u will have,
if (not (a == false)); puts 6; end
or my way, if (not a.false?); puts 6; end

:slight_smile:

···

On Fri, 2004-10-29 at 14:18, David A. Black wrote:

On Sat, 30 Oct 2004, Zach Dennis wrote:

David

33

David A. Black wrote:

<>

Almost always :slight_smile:

irb(main):004:0> a = false
irb(main):005:0> if (a); puts 2; end
=> nil
irb(main):006:0> if (not a.nil?); puts 6; end
6
=> nil

:slight_smile: You are correct , thx for the correction.

Zach

34

"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

35

Jean-Hugues ROBERT wrote:

[snip]

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.

I agree, and well said.

Hal

36

Mohammad Khan wrote:

By definition (in Ruby), nil and false are false, and _everything else_ is true. Its an axiom in Ruby. Just as, in C, 0 is false and all other integers are true.

Thanks, for clarify this. My appology, I didn't know that !

--
Mohammad

Wait a minute,
you are trying to say, nil and false are false.
so we should have
nil == false -> true

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

···

On Fri, 2004-10-29 at 14:16, Mohammad Khan wrote:

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

--
Jamis Buck
jgb3@email.byu.edu
http://www.jamisbuck.org/jamis

37

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

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

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

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.

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.

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

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:

Kind regards
   robert

Yours,
    JeanHuguesRobert

···

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

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

38

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

39

Thanks. EOM.

···

At 05:02 12/11/2004 +0900, you wrote:

Jean-Hugues ROBERT wrote:

[snip]

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.

I agree, and well said.

Hal

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

40

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

Thanks for your explanation, Jamis.

···

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

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

--
Mohammad