Forum: Ruby block params scoping (was ruby-talk 257917: RE: Using a blo

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Peña, Botp (Guest)
on 2007-07-04 09:04
(Received via mailing list)
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
Gregory B. (Guest)
on 2007-07-04 17:54
(Received via mailing list)
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. :)

Man, this list of changes is fun. :)

-greg

[0] http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9#l41
unknown (Guest)
on 2007-07-04 18:11
(Received via mailing list)
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. :)

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
Gregory B. (Guest)
on 2007-07-04 18:33
(Received via mailing list)
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. :)
>
> 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.
unknown (Guest)
on 2007-07-04 19:00
(Received via mailing list)
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
Gregory B. (Guest)
on 2007-07-04 19:07
(Received via mailing list)
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? :)
Ron M. (Guest)
on 2007-07-04 19:12
(Received via mailing list)
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
Robert D. (Guest)
on 2007-07-04 19:27
(Received via mailing list)
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. :)
>
> 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 :(
unknown (Guest)
on 2007-07-04 19:39
(Received via mailing list)
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? :)

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
Todd B. (Guest)
on 2007-07-04 20:13
(Received via mailing list)
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
Robert O. (Guest)
on 2007-07-05 00:17
(Received via mailing list)
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
Michel B. (Guest)
on 2007-07-05 12:51
(Received via mailing list)
Go on Rails, do it live, straight to the target is the ruby way.

Live fast, do not die young. ^^
Gregory B. (Guest)
on 2007-09-26 01:05
(Received via mailing list)
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. :)
unknown (Guest)
on 2007-09-26 01:07
(Received via mailing list)
Hi --

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

> feature in that behaviour.  But I am open to enlightenment. :)
I thought you might ask that :-)  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
This topic is locked and can not be replied to.