---2049402039-479587336-1183561089
0980
Content-Type: MULTIPART/MIXED; BOUNDARY="-2049402039-479587336-1183561089=:10980"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---2049402039-479587336-1183561089
0980
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hi --

On Wed, 4 Jul 2007, Gregory Brown wrote:

> On 7/4/07, dblack / wobblini.net <dblack / wobblini.net> wrote:
>> Hi --
>> 
>> On Wed, 4 Jul 2007, Gregory Brown wrote:
>> 
>> > On 7/4/07, Peñá, Botp <botp / delmonte-phil.com> wrote:
>> >> Fr David Black:
>> >> # Method definitions always have their own local scope, so a, b, and
>> >> # string are strictly local to the method.  Blocks pick up the scope
>> >> # that they're created in, and can also create variables that weren't
>> >> # already in that scope.  Those variables disappear when the block
>> >> # exits; the ones that were there already survive:
>> >> #
>> >> #    x = 1
>> >> #    some_method { y = x + 1 }   # same x; new y
>> >> #    y                           # undefined; block's y didn't survive
>> >> #    x                           # same x
>> >>
>> >> Hi David,
>> >>
>> >> How about parameter variables, will its scoping change/stay in ruby2 ?
>> >>
>> >> Currently,
>> >>
>> >> irb(main):011:0> x="testing"
>> >> => "testing"
>> >> irb(main):012:0> 5.times{|x|}
>> >> => 5
>> >> irb(main):013:0> x
>> >> => 4
>> >>
>> >> i'd prefer
>> >>
>> >> x = "testing"
>> >> some_method { |x| y = x + 1 }   # different x; overrides any x
>> >> x                               # => "testing", same x outside
>> >>
>> >
>> > Hi, example from Eigenclass[0]:
>> >
>> > a = 1
>> > 10.times{|a| } # !> shadowing outer local variable - a
>> > a  # => 1
>> >
>> > looks like it throws a warning and behaves as we all want it to. :)
>> 
>> I actually like the current behavior, but I think I'm in a minority of
>> two (me and Guy Decoux, as I recall).  I don't like the warning thing.
>> If the whole point is to make life easy for people who cut-and-paste
>> code blocks and don't want to check the names of the variables (which
>> I don't do, but I gather that's what people want to do), then it
>> should be totally ignored.  A warning means you have to go in and
>> change it, which is what you have to do now.  So I don't see any gain.
>
> I'm in favor of the new behaviour, but am not sure about the warning.
> My feeling is that any time I've used something like
>
> a = 1
>
> foo { |a| }
>
> It was a typo and I'd like to know about it.

It still sort of goes in a circle, though.  If the main goal is not to
use the same-named variable in both scopes, then what difference does
it make which behavior happens when you do it?


David

-- 
* Books:
   RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
   RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
     & consulting:  Ruby Power and Light, LLC (http://www.rubypal.com)
---2049402039-479587336-1183561089
0980--
---2049402039-479587336-1183561089
0980--