Block params scoping (was ruby-talk 257917: RE: Using a blo


#1

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

just asking for ruby englightenment
kind regards -botp


#2

On 7/4/07, Peña, Botp removed_email_address@domain.invalid wrote:

x # same 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. :slight_smile:

Man, this list of changes is fun. :slight_smile:

-greg

[0] http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9#l41


#3

Hi –

On Wed, 4 Jul 2007, Gregory B. wrote:

y # undefined; block’s y didn’t survive

irb(main):012:0> 5.times{|x|}

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. :slight_smile:

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.

David


#4

On 7/4/07, removed_email_address@domain.invalid removed_email_address@domain.invalid wrote:

exits; the ones that were there already survive:

Currently,
x = “testing”
looks like it throws a warning and behaves as we all want it to. :slight_smile:

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.


#5

On 7/4/07, removed_email_address@domain.invalid removed_email_address@domain.invalid wrote:

use the same-named variable in both scopes, then what difference does
it make which behavior happens when you do it?

Well by saying that (and I think you’re right), aren’t you arguing in
favor of a warning? :slight_smile:


#6

I was looking to start developing a ruby program, where would the
best place be to start?
Should I try with just a straight command line version that has all
the functionality then possibly port the idea to a web based
application using rails or just start right in rails.

Regards,
Ron


#7

Hi –

On Wed, 4 Jul 2007, Gregory B. wrote:

already in that scope. Those variables disappear when the block

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


#8

Hi –

On Thu, 5 Jul 2007, Gregory B. wrote:

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?

Well by saying that (and I think you’re right), aren’t you arguing in
favor of a warning? :slight_smile:

My preference would be for it to stay as it now is (assignment
semantics), without a warning. I’ve never been convinced that it’s
such a big problem, and I think it’s a pity to do away with the
assignment semantics which could prove useful.

David


#9

On 7/4/07, removed_email_address@domain.invalid removed_email_address@domain.invalid wrote:

exits; the ones that were there already survive:

Currently,
x = “testing”
looks like it throws a warning and behaves as we all want it to. :slight_smile:

I actually like the current behavior, but I think I’m in a minority of
two (me and Guy Decoux, as I recall).
No three, I guess I have very, very timidely said so, one day, I
should have shouted loudly ;).
Well that will not change the whole thing :frowning:


#10

On 7/4/07, Ronald V. removed_email_address@domain.invalid wrote:

I was looking to start developing a ruby program, where would the
best place be to start?
Should I try with just a straight command line version that has all
the functionality then possibly port the idea to a web based
application using rails or just start right in rails.

Regards,
Ron

Depends on your personality, your goals, how best you learn, etc.
Opinions vary widely on this. I’m in the learn-ruby-first camp.

Some people like to learn ruby while building their ideal web
application. There are a couple of things to be aware of with such an
approach (using rails as an example). You will be learning rails
idioms/practices/additional classes/methods that are not pure ruby.
Think of it like learning right off the bat how to build hotels, but
lacking the foundation of knowledge to build houses, too (i.e. you
learned about building hotels, not architecture, or, as another
example–a math one–you learned you to use Fourier transforms, but
not why they work). As long as you are aware of that, then go for it.

The other thing to be aware of is that you may get frustrated because
your web app won’t come along as quickly as you expected because of
that lack of foundation.

The straight answer is, do whatever you think is best for your goals.
Not much of an answer, but there you go.

Todd


#11

I think it’d be better to start on the web, if that’s the final target
of
the app. If you make your application console-based, and then end up
needing to port it to the web, you’ll have to do some major reworking,
and
perhaps throw away large parts of your code. But, even if it is a bit
harder, starting off with web development may be better, IMO.

Robert


#12

On 7/4/07, removed_email_address@domain.invalid removed_email_address@domain.invalid wrote:

My preference would be for it to stay as it now is (assignment
semantics), without a warning. I’ve never been convinced that it’s
such a big problem, and I think it’s a pity to do away with the
assignment semantics which could prove useful.

Can you show an example of where it might be useful? I was under the
impression that it simply reassigned to the last value passed into the
block (at the end of it all) and was having a hard time of finding a
feature in that behaviour. But I am open to enlightenment. :slight_smile:


#13

Go on Rails, do it live, straight to the target is the ruby way.

Live fast, do not die young. ^^


#14

Hi –

On Thu, 5 Jul 2007, Gregory B. wrote:

feature in that behaviour. But I am open to enlightenment. :slight_smile:
I thought you might ask that :slight_smile: I can’t think of anything brilliant
right now, but if I do remember an example (and I know I’ve seen some
in the past, though probably nothing you can’t do some other way) I’ll
send it along.

David