Re: Block-local variables - obsolete?

Charles Oliver Nutter wrote:
> Only block parameters are now always local to the block; variables from
> enclosing scopes are still visible. The ; syntax, then, is to specify
> certain names should be forced local, rather than defering to the outer
> scope.
is this really the difference? both produce the "shadowing outer local
variable" warning:

irb(main):001:0> $VERBOSE = true
=> true
irb(main):002:0>   foo = bar = :outer
=> :outer
irb(main):003:0>   1.times { |foo; bar| }
(irb):3: warning: shadowing outer local variable - foo
(irb):3: warning: shadowing outer local variable - bar
=> 1

but I see now: the difference between ; and , is that ; ascertains that
all variables after it don't get assigned to, regardless of the number
of parameters given:

  semicolon = proc do |foo; bar|
    [foo, bar]
  end
  comma = proc do |foo, bar|
    [foo, bar]
  end

  semicolon.call 1      # => [1, nil]
  comma.call 1          # => [1, nil]
  semicolon.call 1, 2   # => [1, nil]
  comma.call 1, 2       # => [1, 2]

what could be the purpose of "declaring" local variables without
assigning a value to them? you say it is about forcing block-local
variables. then the use-cases are situations like this:

  foo = :outer

  let_my_foo_alone do |bar; foo|
    foo = something
    foo.mess_with_me!
  end

  foo  # should still be :outer

if this is the use-case, it should not throw a "shadowing outer local
variable - foo" at me.

and how do I make a block parameter local then? since this doesn't work
(duplicated argument name):

  node = get_root_node

  node.children.each do |node; node|
    node.check_something
  end

  node.check_another_thing

I would have to do something as strange as this to avoid the warning:

  node.children.each do |_node; node|
    node = _node
    node.check_something
  end

(this example is actually a simplified version of a REXML method that
generates such warnings.)

"shadowing outer local variable" is one of the top 10 things for me that
make porting to Ruby 1.9 hard. there should be an obvious way to fix
these warnings. and there should be an obvious use-case for a new syntax
element :)

[murphy]