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 ?
On 7/4/07, Peña, 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 ?
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 ?
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.
David
···
On Wed, 4 Jul 2007, Gregory Brown wrote:
On 7/4/07, Peña, Botp <botp@delmonte-phil.com> wrote:
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.
···
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ña, 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.
>> 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).
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
···
On 7/4/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
On Wed, 4 Jul 2007, Gregory Brown wrote:
> On 7/4/07, Peña, Botp <botp@delmonte-phil.com> wrote:
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.
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ña, 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?
Well by saying that (and I think you're right), aren't you arguing in
favor of a warning?
···
On 7/4/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
> 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?
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.
On 7/4/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
> 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?
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.
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
···
On 7/4/07, Ronald Valente <rawn027@gmail.com> 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.
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
···
On 7/4/07, Ronald Valente <rawn027@gmail.com> 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
--
Robert W. Oliver II
CEO of OCS Solutions, Inc., Web Hosting and Development
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.
···
On 7/4/07, dblack@wobblini.net <dblack@wobblini.net> 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.
Go on Rails, do it live, straight to the target is the ruby way.
Live fast, do not die young. ^^
···
On 7/4/07, Robert Oliver <rwoliver2@gmail.com> wrote:
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
On 7/4/07, Ronald Valente <rawn027@gmail.com> 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
>
On 7/4/07, dblack@wobblini.net <dblack@wobblini.net> 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.
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.
