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.