On Sun, Feb 02, 2003 at 01:16:02PM +0100, ts wrote:
> B> It's difficult to see how that could be made consistent with the proposed
> B> new behaviour; you can't have a block-local value for 'a.a', because it's
> B> not a variable, it's a method call.
> 
>  Not really sure but I think that you'll get a warning if you put something
>  else than a local variable in ||

Hmm. Well, that's made me think. I have a suggestion which is even more
radical than Matz's:

* Define block parameters to be the same as regular assignment
* Have NO block-local scope introduced whatsoever
* That's it

For example:

   [1,2,3].each do |x|
     y = x * 10
   done
   puts x,y

will print "3" and "30", regardless of whether x and y were assigned to
previously, or what values they had if they were.

Benefits:
- No longer violates the POLS, where the persistence of x and y depends on
  whether they were defined earlier
- Mostly backwards compatible (would only fail where 'puts x,y' in the above
  example relied on that being interpreted as 'puts self.x,self.y')
- There is no shadowing, and therefore no mandatory warning required
- Officially blesses the (somewhat dubious) practice of |$m| and |a.a|
- Very simple to understand

Downside:
- May be frowned upon by computer scientists (however, the current
  behaviour, when investigated in detail, is also frowned upon)

It would be worth generating a warning (-w) if a variable is first defined
within a block, and subsequently referenced outside it. This is because
scripts written to rely on this behaviour would not work under older
versions of Ruby.

If the above is considered too clunky, then I'd rather go to the whole other
extreme: block parameters are proper formal parameters, they are named like
local variables but shadow them, and constructs like |$m| and |a.a| are
outlawed. But then we're back to the pros and cons of having other
block-local variables which aren't parameters.

The trouble with the current behaviour is it _looks_ like formal parameters
(it had me fooled, anyway), but isn't.

Regards,

Brian.