On Sat, 30 Oct 2004 13:38:02 +0900, Austin Ziegler <halostatue / gmail.com> wrote:
> 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.
> 
> 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?.

If I am not mistaken this is probably something inherited from
smalltalk. Consider the code:

class False
  def false?
    yield
  end
 
  def true?
    nil
  end
end

# You can guess what True looks like...

def st_if(obj)
  yield if obj.true?
end

def st_unless(obj)
  yield if obj.false?
end

st_if True.new do
  puts "Hey!"
end

st_unless False.new do
  puts "There."
end

# results in:
# Hey!
# There.
######

I quite like how smalltalk handled conditionals. It seems fundamental
rather than inventing a value to look for. It also fits duck typing
better. For example, you could make more than just nil and false
trigger an unless expression. This also gives a better view of why
there could be more than one false value in Ruby even though Ruby does
not follow this model completely.

:)
  Brian Mitchell