From: David Alan Black <dblack@...>
Date: 2002-07-09T19:28:32+09:00
Subject: Re: for ... else ... end

Hi --

On Tue, 9 Jul 2002, Sean Chittenden wrote:

> Hmm...  I work around not having this construct constantly when doing
> database work.  After talking with Holden about this on IRC, I think
> the following examples are helpful.
>
>
> dbh.select_all(sql) do |row|
>   # do something with row
> else
>   puts "No rows returned!"
> end

To me this introduces a seriously criss-crossed quality to the logic
flow.  You'd end up with things like:

  arr = [1,2,3,4]
  f = arr.find_all {|n| n > 4 else puts "Not found"}

> for elt in arr
>   puts elt
> else
>   puts "No rows processed"
> end
>
>
>
> Which opens the door for:
>
> for elt in arr
>   puts elt
> else
>   puts "no rows"
> ensure
>   puts "done looping"
> end
>
>
> Hmm...  I think else is the correct word because it is short hand for
> typing out:
>
> if [].length > 0
>   for elt in []
>     puts elt
>   end
> else
>   puts "now rows"
> end
> puts "done looping"
>
> The example immediately above strikes me as a way of working around
> the language, as opposed to the language doing what you want it to.
> ::shrug:: My $0.02.  -sc

  puts if arr.empty? then "no rows" else arr end
  puts "done looping"

(Couldn't resist :-)

How about:

  if arr.empty?
    puts "no rows"
  else
    for elt in arr
      # do stuff
    end
  end

But in any case, I agree with Det who pointed out that this
(determining whether a loop is executed/entered at all) is different
from the 'break'-trapping scenario.


David

-- 
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web:  http://pirate.shu.edu/~blackdav