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

Kind regards

    robert