My second day of learning Ruby (and my seconds feels)

Ruby
1

Hi all,

Thanks for your anwers yesterday. Are you ready for my next day of
learning Ruby? :wink:

First impressions of ranges:

let’s try ranges as sequences:

irb(main):271:0> (0…2).each { |bb| puts bb }
0
1
2
=> 0…2
irb(main):272:0> (0…2).each { |bb| puts bb }
0
1
=> 0…2

very fun. Now let’s try ranges as conditions:

irb(main):282:0* a=[ “aaa”, “bbbb”, “bbbbbb”, “ccc”, “dddddd” ]
=> [“aaa”, “bbbb”, “bbbbbb”, “ccc”, “dddddd”]
irb(main):283:0> a.each { |b| puts b if b=~/b/…b=~/d/ }
bbbb
bbbbbb
ccc
dddddd
=> [“aaa”, “bbbb”, “bbbbbb”, “ccc”, “dddddd”]
irb(main):284:0> a.each { |b| puts b if b=~/b/…b=~/d/ }
bbbb
bbbbbb
ccc
dddddd
=> [“aaa”, “bbbb”, “bbbbbb”, “ccc”, “dddddd”]

“Oups it did not it again!”

… and … seems not working on the same way if you use ranges as
sequences or ranges as conditions. My point of view: (unless I’m making
a mistake) It gets confusing.

First impressions of blocks:

irb(main):293:0* a=[ “aaa”, “bbbb”, “bbbbbb”, “ccc”, “dddddd” ]
=> [“aaa”, “bbbb”, “bbbbbb”, “ccc”, “dddddd”]
irb(main):294:0> a.each { |a| puts a }
aaa
bbbb
bbbbbb
ccc
dddddd
=> [“aaa”, “bbbb”, “bbbbbb”, “ccc”, “dddddd”]
irb(main):295:0> a
=> “dddddd”

a is changed. scope of the block is not duplicate/separate?

Florent,

2

Florent G. a écrit :

dddddd
=> [“aaa”, “bbbb”, “bbbbbb”, “ccc”, “dddddd”]
irb(main):295:0> a
=> “dddddd”

a is changed. scope of the block is not duplicate/separate?

I’ve got my anwser at Chapter 7, Part I of pickaxe Ruby book:

Variable Scope, Loops, and Blocks

(…cut…)

However, if at the time the block executes a local variable already
exists with the same
name as that of a variable in the block, the existing local variable
will be used in the
block. Its value will therefore be available after the block finishes.

Florent,

3

On 10/19/06, Florent G. [email protected] wrote:

… and … seems not working on the same way if you use ranges as
sequences or ranges as conditions. My point of view: (unless I’m making
a mistake) It gets confusing.

Personally, I don’t think I ever saw someone use a range as a
condition. I don’t even know if they’re supposed to be used that way,
since the name “range” pretty much implies “sequence” rather than
“condition” to me. What were you trying to do in your example?

First impressions of blocks:

a is changed. scope of the block is not duplicate/separate?

IIRC, a block can “see” and use variables in the scope immediately
outside it. This is intended, and useful. They work more like the code
you put inside a loop than the code you put inside a method call.

Would you do the following in another language?

for (i = 0; i <= 10; i++) {

i = some_array[i];

}

4

On 10/19/06, Bira [email protected] wrote:

On 10/19/06, Florent G. [email protected] wrote:

… and … seems not working on the same way if you use ranges as
sequences or ranges as conditions. My point of view: (unless I’m making
a mistake) It gets confusing.

Personally, I don’t think I ever saw someone use a range as a
condition. I don’t even know if they’re supposed to be used that way,
since the name “range” pretty much implies “sequence” rather than
“condition” to me.

It’s the allmighty flip-flop operator*. Useful only for obfuscating
code. It’s not worthy of your attention unless your implementing ruby.

http://redhanded.hobix.com/inspect/hopscotchingArraysWithFlipFlops.html

5

On Thu, Oct 19, 2006 at 07:37:02PM +0900, Florent G. wrote:

dddddd
… and … seems not working on the same way if you use ranges as
sequences or ranges as conditions. My point of view: (unless I’m making
a mistake) It gets confusing.

The difference between … and … in a conditional is a little different
than when used in a range. This is described in the PickAxe book on p
327 Second Edition PDF 2007-09-20. The difference is that the two-dot
form evaluates the second condition when it enters the true state and
the three-dot form does not. So, for example, on a given iteration if
the first conditional caused the ``state machine’’ to go into the set
state and the second conditional evaluated to true, the two-dot form
would return true but switch the state back to unset and the three-dot
form would not. Here is the example code from the PickAxe book (spruced
up a bit):

#! /usr/bin/ruby -w

test behavior of range operator in conditional

require ‘pp’
a = (11…20).collect {|i| (i % 4 == 0)…(i % 3 == 0) ? i : nil}
pp(a)
b = (11…20).collect {|i| (i % 4 == 0)…(i % 3 == 0) ? i : nil}
pp(b)

Which outputs:

[nil, 12, nil, nil, nil, 16, 17, 18, nil, 20]
[nil, 12, 13, 14, 15, 16, 17, 18, nil, 20]

The two-dot form evaluates both conditionals when i is 12, it returns
true but since the second condition evaulates to true the state machine
is changed back to unset and subsequent values do not get printed until
the first contitional returns true again.

Note that even when the second conditional returns true and the state
machine is switched to unset, the expression returns true. This is true
for both forms.

6

Bira a écrit :

Personally, I don’t think I ever saw someone use a range as a
condition. I don’t even know if they’re supposed to be used that way,
since the name “range” pretty much implies “sequence” rather than
“condition” to me. What were you trying to do in your example?

In the Ruby’s pickaxe book Chapter 5:

Ranges

  • Ranges as sequences
  • Ranges as conditions
  • Ranges as intervals
7

Simen E. wrote:

It’s the allmighty flip-flop operator*. Useful only for obfuscating
code. It’s not worthy of your attention unless your implementing ruby.

IIRC, it’s being dropped in Ruby 2.0 anyway.