I like it.
What about a ‘multilpe_of?’ function. I hope this makes sense:
You could have a multiple_of? function so you could say multiple_of?(3)
and it would give you every third iteration. You could also add another
parameter that would subtract back that number like multiple_of?(3,2)
would give you 1,4,7,10 etc. That would make even? be multiple_of?(2)
and odd? be multiple_of?(2,1)
@count_ % multiple == back
From: “Hal E. Fulton” firstname.lastname@example.org
Date: Tue Aug 06, 2002 02:25:23 AM US/Eastern
To: email@example.com (ruby-talk ML)
Subject: Re: Super-iterator? (long)
Just for fun, I’ve converted your tests to Test::Unit format. This is
a drop-in replacement for everything after the module Enumerable
Neat. I need to get into that habit.
A few comments:
- I’m still not sold on the whole thing But it’s extremely
Oh, neither am I (completely sold). It’s an experiment.
I’m sold on my own “motivations” but not on this solution.
- I had to change #next to #i_next, because it was next’ing integers
Huh?? next is a method of IteratorVar… it shouldn’t cause any
kind of conflict. Can you explain?
- #odd? and #even? are, in my view, too “meta”. When I see “x.odd?”,
it’s virtually impossible not to expect that it’s testing an integer
I agree. But I couldn’t think of what else to call them. When I want
to do things alternately in a loop, sometimes I want the even-numbered
iterations, and sometimes the odd.
- Are you sure you want #next (or #i_next, or whatever) to consume
items? What if you want to grab the next item, but also want to
iterate to that item in the normal way? You seem to have less
functionality here (if I’m right about that) than you would with one
of the “index” methods.
According to my own usage patterns, I usually do want it to consume.
If I were writing some kind of parser, it might be different.
- I’ve done some fancy #to_s’ing… not sure if I should have to do
that. Anyway, I’ve done it, just to get the tests to pass initially.
Actually, according to the way I was doing things, I should have
said x.next.value instead of just x.next (assuming no one actually
wants to store an IteratorVar). Maybe that would help.