From: Hugh Sasse Staff Elec Eng <hgs@...>
Date: 2000-07-11T11:54:32+01:00
Subject: [ruby-talk:03932] Re: Array.uniq! returning nil

On Fri, 7 Jul 2000, Hal E. Fulton wrote:

Our mail has been dead for a few days...

> That's a very interesting idea, Hugh. But how does
> the caller know that the cut failed?

Which caller? I ask because I wrote:

> > a.modifier!().cut.method1.method2

So a calls modifier!(), its own method.  Then (pseudocode):

    case a.modifier!
    when a
        This is OK, because cut will be a no-op. a will get
        passed on to method1 and so on...
    when nil
        Firstly, a knows it has returned nil, because one of
        its own methods (modifier!()) caused this to happen.
        Secondly, the caller of cut is no longer a.  Because modifier!
	returned nil, this becomes nil.cut so the caller of cut is now
	nil.  nil cannot do much anyway.
    end

If you mean how will the enclosing function know that the statement
a.modifier!().cut.method1.method2
was completed or not, then the answer is that it will not know.
If it makes a material difference then this construct would not
be used.  It is a bit like asking, "once you have exited an
'if...else...end' block, how can you tell which path was taken?"
One solution would be methods with side-effects, if you needed
to know.

This sort of breaking of a chain has been used to great effect
in Icon.  One thing I like about Icon is that one can write

    if a < b < c

and this works as follows:
when a < b then (a < b) returns b. Otherwise it quietly fails.
This b then goes on to become part of b < c, which may fail.
Only if the whole thing is successful will the body of the if
statement be executed.  This philosophy also means that 

    if 0

is actually successful, which seems odd at first.  I'm not saying
that Ruby should follow this pattern, but this style of programming
can be clear when used in an appropriate place.
> 
> Hal
> 
    Hugh
    hgs@dmu.ac.uk