On Saturday 20 September 2008 16:07:20 tekwiz wrote:
> On Sep 20, 3:32=A0pm, Phlip <phlip2... / gmail.com> wrote:
> > Phlip wrote:
> > > tekwiz wrote:
> >
> > >> This is what roodi would have me do
> >
> > >> =A0 (0...str.size).each do |i|
> > > 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 ...
> >
> > It also hints at:
> >
> > =A0 =A0str.each do |ch|
>=20
> So, it's a code-readability issue and not a functional or complexity
> issue?

These things are not entirely separate -- readable code is more likely to b=
e=20
functional and maintainable.

Or, maybe a better way of saying it is, the code should not merely be=20
readable, it should be expressing your intent.

Each is far more abstract than for. Take a simple array:

a =3D ['one','two','three']
for i in 0...a.size
  puts "Give me a #{a[i]}"
end

That's more prone to not work, as there are more visible moving parts, whic=
h=20
means more for you to think about, and more that can go wrong -- you might=
=20
type the wrong variable name in the a[i], for example, or type 0..a.size=20
instead of 0...a.size.

It also doesn't express your intent. You don't really need to know or care=
=20
where you are in that array, in this particular algorithm. You only need to=
=20
know which item you're going to print right now. So:

['one','two','three'].each do |x|
  puts "Give me a #{x}"
end

Shorter, more readable (to me), quicker to type, and has the added benefit=
=20
that in the above example, that array falls out of scope as soon as the loo=
p=20
ends, so it can be collected sooner.

It also gives you a bit more flexibility. Suppose you're iterating over=20
something that someone passed in -- that means that I have to pass in=20
something that behaves like an array. It needs to have an accurate [] metho=
d,=20
probably supporting random access, even if you'll only access it=20
sequentially. It needs to have a length method, etc.

Which makes things quite a bit more awkward. What if I'm reading lines from=
 a=20
file? Your way would force me to count every line in the file before I even=
=20
get started. What if it's a complex computation, like all the primes less=20
than a given number? I have to calculate them all out ahead of time, and=20
either store that array (wasting memory), or recalculate them from the=20
beginning.

There's more to it, of course -- you could imagine an each method which run=
s=20
in parallel threads, and I'm sure someone has written such a thing.

None of these will apply to every situation. It's entirely possible it's an=
=20
internal data structure. Even internal data structures could benefit from=20
some flexibility, but maybe you'll never touch this algorithm again.

But then, I don't really see a downside to doing it with 'each', instead=20
of 'for', other than that 'for' is what you're used to.