From: Sean Russell <ser@...>
Date: 2001-06-04T00:29:05+09:00
Subject: [ruby-talk:16188] Re: The Block Problem -A suggestion

I'm trying to reduce my comments on this topic; I think I've made
it pretty clear where I stand on the issue.  I do have one last
parting shot, though.

On Sun, Jun 03, 2001 at 04:51:03PM +0900, Guy N. Hurst wrote:
> I think matz indicated a desire for a flattened scope here 
> (that is, auto-exporting), which I can't imagine would break any 
> existing code. Maybe it is not done yet because it is hard to do?

I think this is the crux of the matter.  Matz should decide what
sort of scope {...} and do ... end have, and then base the scoping
rules on that.  It seems to me that much of the confusion and conflict
about this issue arises out of the "ambiguous" scoping status of
these blocks/procs.

If blocks are flatly scoped, then side-effects are *to be expected*, and
x = 5 ; 10.times {|x|} shouldn't suprise anyone.  Blocks are, after all,
by definition, flatly scoped.  I think that the only reason why people
encounter this problem is because, as programmers, we see the '{ ... }'
and expect the code to be locally scoped -- this is what most programming
languages do.

If blocks are locally scoped, then they should have locally scoping rules, 
and they should behave like methods.  This would be the behavior most
people would *expect*, although it may not be as powerful, useful, or
elegant.

My point being that, if you define the scoping context, the scoping rules
define themselves, and people easily know what to expect from any given
code.

I don't have a preference for locally or flatly scoped blocks; either is
fine by me, as long as the scoping context is *defined* and then the rules
are consistent with the context.

--- SER