Dave:
> 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.

Dave, your proposal is perfectly fine. I hardly dare to announce my Ruby
abilities barely exceed total beginner who had read all the currently
available material once. If only I had such insight and wisdom as you and
many others on the list seem to have I'd be not only much better coder and
developer but a Ruby developer. Then such test would be done in no time but
now it's better to dig the grave for stupid thoughts with help from the
others.

My style has been so far, and in the future unless I get requests to do
otherwise, to raise different topics, cases and pieces of code under some
peer thought and design. Most of the time I miss the target (at least 80%)
but every now and then I feel I might have hit the spot and if we're not
getting better Ruby at least have I managed to provide some thought-food for
powerful and wise brains.

This FailureClass is probably one of my personal failures or misses but
hopefully it has cleared the nature of Ruby for someone else than me too. 

In any case, I agree that the best way to communicate would be to develop
the random thought or the idea, raise it and when it's mature, tested and
personally evaluated to be able to survive, discuss about it with others. I
do, however, lack abilities to do so. So I raise an issue and let the
people, you, express their viewpoint and judge.

Now, I got your counter arguments and I'm very happy.

> However, I have a problems with the idea:
> 1. Performance. 
> 2, Clarity.

If the FailureClass is the right way to go it should be implemented in a
interpreter and be as fast as possible. I agree the kind_of? trick not only
makes code uglier but is probably slower too.

> 3. Symmetry. 
>    if failure is not false, then
>      "dog" =~ /cat/
>    would be true, which would be somewhat confusing?

I see your point. Failure should be evaluated to false in boolean context.

But apart from that I feel my thoughts are not clear yet. I seem to have a
problem about double meaning of nil and my first solution was to make:
- failure = FailureClass.new(), and use (return) failure when 
  something requested can't be done
- nil, and use it to specify something is undefined

So let's see. If 'gets' returns a string if it's able to perform it's
function and failure if the stream is at the end

  while str = gets
    print str
  end

would work five if failure is false in the test. Then assume we have
getNextPacket which returns:
- instance of Packet if it can, this means that it could return
    - nil if the packet is undefined (for example the packet was totally
broken)
- failure if it can't get next packet

  while packet = getNextPacket
    print packet.content if packet
  end

Now we have two different possible meanings here. At 'while' we would like
to check if the returned packet is not a failure, and process it if
everything is fine. That means that nil has to pass the test. On the other
hand 'if' would like to check if the packet is really defined because we
can't print an undefined packet. So we can't allow nil to be printed and
that means nil shouldn't pass the test.

So maybe the code should be

    print packet.content if defined? packet

Which in turn leads to my second thought. The FailureClass was proposed
because nil gives me feeling of null which has been the symbol denoting
undefined in the databases world (and widely elsewhere too). But we can turn
the tables and let nil be as it is and introduce UndefinedClass instead.
Then nil would retain the meaning of failure. 'defined?' would return
kind_of?(UndefinedClass) or something.

My example probably sucks, but it doesn't matter. I'm sure this version is
as bad thing as the original, but I'm happy to hear your thoughts.
(Actually, the real reason is that this mail is way too long already. :)

	- Aleksi