From: Jakub Travnik <j.travnik@...>
Date: 2002-06-12T17:41:40+09:00
Subject: Re: ruby-dev summary 17252-17356

James F.Hranicky wrote:
> On Tue, 11 Jun 2002 13:20:03 +0900
> "Minero Aoki" <aamine@mx.edit.ne.jp> wrote:
> 
> 
>>  * Backward compatibility takes precedence over all.
>>
>>  * The problem is that block localization may be broken with
>>    name collision between inside of the block and the outside.
>>
>>  * It is not true that ruby does not have block local variables.
>>    The problem is that local variables does NOT shadows outer
>>    local variables.
> 
> 
> Should we perhaps take a vote and see how many folks have ruby
> programs that depend on block parameters referencing outer variables?

I would vote for local behaviour = shadowing.
And special syntax for non-shadowed:

   a=nil;(1..2).each{|{a}|}; puts a # prints 2

This is since my mind wants to concern always to local behaviour.
Attention to all other non-local scopes is more painful for the mind.


> I've always treated block variables as block local -- perhaps breaking
> backwards compatibility won't have such a huge impact.

This impact can be minimized. For transition sources could declare
behaviour they want. Like in the python (which imports functionality by
declaring what you want) imho, there could be syntax for specifying
that all of this file will use behaviour of ruby1.8 (or whatever).
example:
#pragma localshadow
but many other ways are possible.

This way can be used for transition for other differences between versions.
i.e priority of parenthesis:

   # this does not work in ruby1.6, extra parenthesis are needed
   puts (1..2).collect{|x| "#{x}"}

This also breaks some code. And new way is imho better, but transition
of some code will be required.

Problem with #pragma approach is eval. You cannot know what behaviour was
intended, but simple inheriting of caller pragmas will almost always work.

Ruby interpreter could detect where behaviour will be different (this is
relatively easy for shadowing) when run with some parameter. This will make
process of porting old way to new easy. It is also possible to use list of these
warnings to update code to new ruby version automatically.

I think that this isn't the last change to ruby that could break some code.
Ruby needs syntax for specifying intended version behavoiur.


Jakub Travnik
jabber://jtra@jabber.com

disclaimer:
I'm not native english speaker.
At least, I'm not trying to convince you all to learn czech ;-)