Hi –
I’ve got the feeling that this thread is
drifting from the original problem (detect
successful looping) to the discussion about
some related but different problems.
One problem is the definition of “success” in looping. Personally I
don’t think there’s any such thing. This:
.each {|x| puts x}
is completely successful, as far as I can see. Python apparently
considers success to be indicated by ‘break’, which I think is a
style/taste position which I would not like to see given
language-level blessing.
[…]
Problem 1: Identify bypassing (e.g. empty array)
and declare coding that shall run in this case
if array.empty? … No, seriously
This includes testing results:
res = array.find_all { }
if res.empty? …
Problem 2: Identify interruption (by break or throw)
and declare coding that shall run in this case
I would say: if you want to branch this way, then use catch/throw with
your break (rather than trying to enhance ‘break’ so that it more or
less duplicates what catch/throw already does).
Problem 3: Identify full passing (no break)
and declare coding that shall run in this case.
This goes hand-in-hand with #2.
David Alan Black schrieb:
if array.empty?
puts “Empty array”
else
array.each {|e| puts e}
endOk, this solves problem 1 in some way (although it
does not ‘identify’ the bypassing itself, but checks
explicitly a precondition). So in relation to loops
you would check a condition twice:if a > b
while a > b
…
end
else
…
end
I see this as a case of this:
if x
while y
…
where x and y happen to be the same test. I would say: it’s easier to
live with the occasional coincidence like this, than to introduce
language-level constructs to handle it.
[…]
So the complete example looks something like:
if array.empty?
print “Loop bypassed \n”
else
catch (:done) do
for i in array
if #
print “Interruption branch\n”
throw :done
end
print “Working in loop \n”
end
print “Loop terminated without break\n”
end
end
I would rewrite that like this:
if array.empty?
puts “Array is empty – no test”
else
if array.detect {|e| puts “Working in loop”; }
puts “Condition met”
else
puts “Condition not met”
end
end
Hum, the discussed construct with different
for-branches would simplify things … don’t you
think too?
I don’t know… it seems like a lot of what’s in this thread is very
complex, at least to my eye, compared to the simplicity Ruby offers.
David
···
On Wed, 10 Jul 2002, Dirk Detering wrote:
–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav