"Hal E. Fulton" <hfulton / austin.rr.com> writes:

> This seems like a good idea to me...  Other comments?

In an abstract sense it sounds like a good idea -- you could
incorporate reason codes, messages, retry flags and so on in a failure 
object.

However, I have a problems with the idea:

1. Performance. Right now, the test for false or nil is trivial in the 
   interpreter. With FailureClass, we'd be looking at a method
   dispatch to check for kind_of?

2, Clarity. I _like_ being able to say

      while gets
        ...
      end

   or

      if string =~ /cat/

   Somehow,

      while !gets.kind_of?(failure)

   just doesn't do it for me.

3. Symmetry. Look at something like "string =~ /cat/"

   If the match succeeds, it returns the offset of the start. That's
   not nil or false, so the expression is true. But if the match
   fails and the expression returns a failure object, what do we
   do. Do we build in to the interpreter the fact that failure is
   false? There mau be some issues there, noy just with performance,
   but also logically. Alternatively if failure is not false, then

     "dog" =~ /cat/

   would be true, which would be somewhat confusing?


So, I've got a proposal.

Why don't the proponents of the idea get together and redefine a
portion of the built-in library to use a FailureClass. Publish the
result so we can all see what the implications are, good and bad.

Regards


Dave