On Sat, 12 Feb 2005 06:31:19 +0900, Zach Dennis <zdennis / mktec.com> wrote:
> Trans wrote:
> > Trans wrote:
> >
> >>>I personally always define them as:
> >>>def a?
> >>>       !!@a
> >>>end
> >>
> >>Nice, thanks.
> >
> >
> > Oops. Except that with Ruby it's not a simple as true and false, there
> > is also nil. I think passing nil through unchanged is advantageous as
> > it allows for yes, no, maybe (i.e. three state) value.
> >
> 
> I have failed to see when using three state's is needed. Could you
> provide an example where "my_obj.a?" would behave different if nil/false
> meant nil/maybe ?

I think he means nil to be the maybe. For instance, in the ri
libraries, a few of the method signatures look like this:

  def get_method_stuff(klass, method, is_class_method = nil)

if is_class_method is true, it only looks for the method in the class
method namespace. if false, it only looks in the instance method
namespace But if it gets nil, it checks both; because it takes nil to
mean "unspecified".

Personally, I'm a little wary of this kind of stuff; I think I'd
prefer to use symbol flags:

  # method_type can be :class, :instance, or :either
  def get_method_stuff(klass, method, method_type = :either)

But still, the three-state true/false/nil way does seem to have some
precedence in the standard library.

cheers,
Mark