tekwiz wrote:

>>> It leaves you closer to a refactor to .map or .inject or .select or
>>> .reject or .delete_if or .each_index or .each_with_index or ...

> So, it's a code-readability issue and not a functional or complexity
> issue?

'for' is arguably more readable. And it's not a performance issue - I suspect 
the opcodes will be the same. It is very much a technical issue.

Good code is readable, minimal, and maintainable. Maintaining code requires
adding new features. Code should always be as ready for change as possible, so
much of our design rules (such as "object orientation") are really rubrics for
improving the odds that the next change comes easy.

This is an easier change...

   array.each{|x| ... }  ->  array.map{|x| ... }

...than this:

   for x in array ...  -> array.map{|x| ... }

Further, your original example was very C-like. The iteration variable was the
array's index. Most iteration directly addresses each array's element, without
regard to its index. So 'for i in 0...str.size' is often more excessive than
'for x in str'.

Using .each leads to the correct mindset. Put another way, 'for' is an obsolete
concept - a legacy of languages without true iteration.

-- 
   Phlip