GGarramuno,

I may be wrong, but I don't think I've seen a 'times' method to any class
but an Integer. You could almost expect that when dealing with:

i = 10 # somewhere out there
# and then somewhere else...
i.times do something end

that i is an Integer or will be treated like one. I don't think that in all
iterative situations you should use the times method, but I disagree that it
is merely a 'cute' thing to have in Ruby, but nothing worthy of real code
use. Even if you switched your above code to:

i = 10#somewhere out there
#somehwere else
for x in (1..i) do
	puts x; end

You still dont' know what class i is. You are assuming it is an Integer, and
it should be, but you still have the same amount of nonclarification in your
for loop as you do with your times iterator. You are making an assumption
that you or whomever else typed in that code made sure that i will be an
integer.

Of course if the times method is used by another class then my statement is
invalid because then there is an extra layer of nonclarification to what
class 'i' is, but until then I am not seeing the confusion you speak of. The
same assumptions are being made or should be made by the code reader, 'i' is
an Integer in a for loop or a times iterative method.

Zach





-----Original Message-----
From: GGarramuno [mailto:GGarramuno / aol.com]
Sent: Wednesday, January 21, 2004 3:00 AM
To: ruby-talk ML
Subject: Re: New to Python: my impression v. Perl/Ruby


"Zach Dennis" <zdennis / mktec.com> wrote in message
news:<AKEKIKLMCFIHPEAHKAAICEOHHFAA.zdennis / mktec.com>...
> Ville>Though "sending messages" to int literals is a syntax error.
>
>     >Phil> 10.times do something end
>
>     >Phil> is somehow so clear.  It's almost zenlike.
>
> Ville>It's cute and fun to write, but less cute for people who have to
read
> Ville>lots of such code in short time.
>
> Ville,
>
> 10.times do something end
>
> How is the the above code less 'cute' for people who have to read lots of
> code?

Well, that isn't too confusing.  But one issue with looping using the
object.method() constructs is when you are dealing with variables.

That is:

10.times do something end

is extremely nice and very clear to read.



However:

i = 10 # somewhere out there

# and then somewhere else...
i.times do something end

is confusing as you have no clue what class i is and as such, no idea
what times may be doing.
In those cases, a for or while loop is preferable and should be
enforced, in my opinion.
In my experience, it is much more common for algorithms to be looping
involving arbitrary numbers stored in variables than predetermined
times, so I also tend to agree that such constructs are cute but not
something I'd likely use often in real code.