On Monday 01 November 2004 03:34 pm, Mohammad Khan wrote:
| You can extend Object
|
| class Object
|    def true?
|        return self == true ? true : false
|    end
|
|    def false?
|        return self == false? true : false
|    end
| end

Ruby allows all objects to eval as true values except the false and nil 
instances. This allows one to easily check if an object was returned from a 
call vs. nil
 
  md = /abc/.match(foo_string)
  if md
    #...
  end

So with what you're saying, we'd have to do:

  md = /abc/.match(foo_string)
  if ! md.nil?
    #...
  end

And to use #true?

  md = /abc/.match(foo_string)
  if md.true?
    #...
  end

Doesn't work, because what you're really asking is

  md = /abc/.match(foo_string)
  if (md != nil and md != false).true?
    #...
  end

So what does #true? gain you?

I suppose one could make a method out of the above if one really disliked 
Ruby's built-in evaluation.

  class Object
    def is?
     (md != nil and md != false)
    end
  end

  md = /abc/.match(foo_string)
  if md.is?
    #...
  end

Personally, the only thing I really feel Ruby lacks in the arena is a 
lower-level form of nil, i.e. nack, instance of NackClass. Sometimes nil is 
useful in its own right as meaning emptiness, other times you really need to 
pass through an unknown result but also might need to pass a flag indicating 
something's not quite right. That's where nack is useful. It's kind of like a 
managable error that can be propigated. Anyway, that's sort of O.T. I guess.

BTW Brian put this out,

  class Object
   def false?
    nil
   end

   def true?
    yield
   end
  end
  
Which is more intersting direction of inquiry, IMHO.

T.