Hi,
I was going through matz’s slides from the Ruby Conference 2003, and was checking out what the slides claimed was the most regrettable behaviour in ruby, namely that in the following code,
def foo
a = nil
ary.each do |b|
c = b
a = b
end
end
b and c are local to the each-block while the variable a which is referred to in the block is not. i assumed that in Ruby2, ‘a’ too would be local to the block and there would be different way to refer to the variable a which is outside the block’s scope.
However, when i checked out the next slide, “Horror Of Horrors!” , in Ruby2, both a and c would be local to the entire method instead!
Now i’m just learning ruby, so i guess i’m missing something or have understood something wrong.
What i’d like to know is how is this new behaviour better than the old behaviour? Compared to Ruby2’s rule, isn’t the old rule more intuitive?
Gavri Savio Fernandez
···
If only God would give me some clear sign! Like making a large deposit in my name at a Swiss bank. - Woody Allen
Simple rule (Ruby 2.0): Block parameters are local to the block,
everything else is not.
Consider the following example (Ruby 1.8):
a = 3
[1,2].each do |a|
p a
end
p a # => 2
This problem is fixed with 2.0 (a => 3).
I am not sure if the ability to mark variables explicitly as block-local
is consider by matz, e.g.:
ary.each do |b| <c, a>
end
or
ary.each do |b|
local c, a
end
For me, this looks not too bad and would fix all problems (hopefully).
This would mean that c and a are block local. By ommiting the “a”
inside < and >, one could access the outer a variable.
Many new things in Rite seem to be strange at the first look, and
luckily, there’s still room for many discussions and improvements.
Regards,
Michael
···
On Mon, Nov 17, 2003 at 03:08:26AM +0900, Gavri Savio Fernandez wrote:
Hi,
I was going through matz’s slides from the Ruby Conference 2003, and was checking out what the slides claimed was the most regrettable behaviour in ruby, namely that in the following code,
def foo
a = nil
ary.each do |b|
c = b
a = b
end
end
b and c are local to the each-block while the variable a which is referred to in the block is not. i assumed that in Ruby2, ‘a’ too would be local to the block and there would be different way to refer to the variable a which is outside the block’s scope.
However, when i checked out the next slide, “Horror Of Horrors!” , in Ruby2, both a and c would be local to the entire method instead!
the point is that you don’t need to explicitly use a declaration of a
variable outside of the scope of the block.
If you want to use block local variables you would just need to do:
ary.each do |normal_var,block_local_var_initialized_to_nil |
use the vars
end
BTW probably you need block local vars rarely (apart from those
declared in the || )
···
il Mon, 17 Nov 2003 03:08:26 +0900, “Gavri Savio Fernandez” Gavri_F@infosys.com ha scritto::
Hi,
I was going through matz’s slides from the Ruby Conference 2003, and was checking out what the slides claimed was the most regrettable behaviour in ruby, namely that in the following code,
def foo
a = nil
ary.each do |b|
c = b
a = b
end
end
b and c are local to the each-block while the variable a which is referred to in the block is not. i assumed that in Ruby2, ‘a’ too would be local to the block and there would be different way to refer to the variable a which is outside the block’s scope.
Simple rule (Ruby 2.0): Block parameters are local to the block,
everything else is not.
Consider the following example (Ruby 1.8):
a = 3
[1,2].each do |a|
p a
end
p a # => 2
This problem is fixed with 2.0 (a => 3).
So, with the new semantics, how do we do things like …
a = nil
some_collection.each do |x|
if some_condition
a = …
break
end
end
Obviously, if we want “a” to end up being the same as one of the values in the collection, there’s probably some iterator other than “each” that will allow for that. However, if the value we want to give it is more complex (or just plain different from the current value of x), what’s the right mechanism?
Sorry, I can’t think of a concrete example this second, but I can remember doing this kind of thing many times in the past … mainly because it always failed until I added the “a = nil” line :-).
I ask because I might as well start preparing for when the current mechanism stops working, by using the “right” … or should that be “Rite” … code now.
the point is that you don’t need to explicitly use a declaration of a
variable outside of the scope of the block.
If you want to use block local variables you would just need to do:
ary.each do |normal_var,block_local_var_initialized_to_nil |
use the vars
end
does this mean that i can include whatever local variables (local to
the block) that i need between the || right after the block
parameters. would such variables not affect any variable of the same
name used outside the block and not have any effect on such variables?
for example,
g = 5; puts g; [1, 2, 3].each do |f, g| puts f, g; end; puts g
now gives me:
5
1
nil
2
nil
3
nil
nil
Under Ruby2, would it give me the following?
5
1
nil
2
nil
3
nil
5
Gavri Savio Fernandez
···
What if everything is an illusion and nothing exists? In that case, I
definitely overpaid for my carpet. - Woody Allen
Simple rule (Ruby 2.0): Block parameters are local to the block,
everything else is not.
Consider the following example (Ruby 1.8):
a = 3
[1,2].each do |a|
p a
end
p a # => 2
This problem is fixed with 2.0 (a => 3).
So, with the new semantics, how do we do things like …
a = nil
some_collection.each do |x|
if some_condition
a = …
break
end
end
This will work exactly the same way as in Ruby 1.8. The assignment
inside the block will assign to the outer variable (a). Any assignment
inside a block with the exception of assignements to block parameter
variables (here x), will be to variables outside the block.
Obviously, if we want “a” to end up being the same as one of the values in
the collection, there’s probably some iterator other than “each” that will
allow for that. However, if the value we want to give it is more complex
(or just plain different from the current value of x), what’s the right
mechanism?
Sorry, I can’t think of a concrete example this second, but I can remember
doing this kind of thing many times in the past … mainly because it
always failed until I added the “a = nil” line :-).
In Rite you won’t need a “a = nil” line anymore. “a=” inside the block
will automatically introduce a variable “a” outside the block.
Hopefully, I don’t tell you something wrong
Regards,
Michael
···
On Mon, Nov 17, 2003 at 07:21:15AM +0900, Harry Ohlsen wrote:
some_collection.each do |x|
if some_condition
a = …
break
end
end
This will work exactly the same way as in Ruby 1.8. The assignment
inside the block will assign to the outer variable (a). Any assignment
inside a block with the exception of assignements to block parameter
variables (here x), will be to variables outside the block.
Ah! Thanks Michael. I completely misread Matz’s slide.
In Rite you won’t need a “a = nil” line anymore. “a=” inside the block
will automatically introduce a variable “a” outside the block.
This is much nicer. I’m more likely to get it right first time, now :-).
, in Ruby2, both a and c would be local to the entire method instead!
, in Ruby2, both a and c would be local to the entire method instead!