.. 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:
----------------------------
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.
.. 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];
}
···
On 10/19/06, Florent Guiliani <fguiliani@perinfo.com> wrote:
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)
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.
···
On Thu, Oct 19, 2006 at 07:37:02PM +0900, Florent Guiliani wrote:
First impressions of ranges:
---------------------------
Now let's try ranges as conditions:
.. 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?
In the Ruby's pickaxe book Chapter 5:
Ranges
* Ranges as sequences
* Ranges as conditions
* Ranges as intervals
> .. 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.
