Johann Hibschman <johannh / uclink.berkeley.edu> writes:

>Well, the most common way I use something like this is as a way to tell
>if I broke out of a loop and where, such as

<snip interesting usage code>

Thanks for your interesting example of how having block params be non-local
can be useful.  Still,  I would say, 

>last_i, last_obj = nil, nil
>data_objects.each_with_index {|obj, i|
>  last_i, last_obj = i, obj
>  if ...
>}

is a safer/cleaner option.  (In this particular case also I might have used
catch/throw rather than a 'break' from the block.)  But, of course, it boils
down to a personal preference.

History seems to indicate keeping block params local is better.  
In my earlier post, I'd mentioned the move away from the C behavior in
C++/Java with loop local variables.  I forgot to mention two more obvious
instances: Lisp and Smalltalk.  Many of the concepts of Ruby have been
inspired by both these languages.  In both, the equivalent of block params
are local: in Lisp lambda params are local and even more specifically block
params in Smalltalk (which are practically identical to Ruby blocks) are
local.  With all due respect to Matz, I find it a very interesting design
choice of moving away from the Smalltalk/Lisp model to the C model in Ruby.

(Matz, this is not meant as any criticism or so.  I'm just very interested
in the reasoning that goes on behind the choices made when designing a
language.  In this vein, the best exposition I've seen on this is Bertrand
Meyer's OOSC --- an excellent description of the concepts of
object-orientation and a superb account of why things are the way they are
in Eiffel.)

Regards,

Raja