using Enumerable when each has arguments?

[Erwin Abbott]

Hi

I've written a number of classes which would benefit from the
Enumerable mixin, but my #each method requires arguments. These are
usually to specify the range of values, like Fibonacci#each(first,
last) or whatever. Since Enumerable's #map, #collect, etc don't take
arguments, how should I proceed? I would be okay with wrapping the
Enumerable methods I need, but that doesn't seem possible. Do I just
have to implement my own #map, #to_a, etc?

Thanks,
Erwin

 

[Robert Klemme]

I've written a number of classes which would benefit from the
Enumerable mixin, but my #each method requires arguments. These are
usually to specify the range of values, like Fibonacci#each(first,
last) or whatever. Since Enumerable's #map, #collect, etc don't take
arguments, how should I proceed? I would be okay with wrapping the
Enumerable methods I need, but that doesn't seem possible. Do I just
have to implement my own #map, #to_a, etc?

Just use Enumerator:

12:54:27 [client_1]: irb -r enumerator
irb(main):001:0> class Foo
irb(main):002:1> include Enumerable
irb(main):003:1> def each(a,b,&bl) (a..b).each(&bl); self end
irb(main):004:1> end
=> nil
irb(main):005:0> Foo.new.each(1,5) {|x| p x}
1
2
3
4
5
=> #<Foo:0x7ef7e9b8>
irb(main):006:0> Foo.new.to_enumeach,1,5).map {|x| x+x}
=> [2, 4, 6, 8, 10]

Btw, is your Foibonacci#each really an instance method or rather a class
method? If it is an instance method you might as well store arguments
in the instance, so you do

Fibonacci.new(1,10).each {|fib| puts fib}

Kind regards

robert

 

[Trans]

Hi

I've written a number of classes which would benefit from the
Enumerable mixin, but my #each method requires arguments. These are
usually to specify the range of values, like Fibonacci#each(first,
last) or whatever. Since Enumerable's #map, #collect, etc don't take
arguments, how should I proceed? I would be okay with wrapping the
Enumerable methods I need, but that doesn't seem possible. Do I just
have to implement my own #map, #to_a, etc?

The standard response is "use enumerator and to_enum". but if you feel
like me, that's equivalent to tying knots in your spaghetti noodles to
save money on rotini.

I heard rumor that a future Ruby will ultimately pass thru each
parameters, but in the mean time you can have a go with Facets
enumerablepass.rb (http://facets.rubyforge.org).

An alternative is to use a functor (a function delegator) for your
parameters, eg.

f = Foo.new
f.range(1,5).each{|x| p x}

T.

 

[Robert Klemme]

The standard response is "use enumerator and to_enum". but if you feel
like me, that's equivalent to tying knots in your spaghetti noodles to
save money on rotini.

I on the other hand am a big fan of Enumerator.

I heard rumor that a future Ruby will ultimately pass thru each
parameters, but in the mean time you can have a go with Facets
enumerablepass.rb (http://facets.rubyforge.org).

That's a good solution.

An alternative is to use a functor (a function delegator) for your
parameters, eg.

f = Foo.new
f.range(1,5).each{|x| p x}

.... which is basically the same as using to_enum - only less portable;
to_enum works with *all* methods.

Kind regards

robert

 

[Trans]

... which is basically the same as using to_enum - only less portable;
to_enum works with *all* methods.

That true. But at least it reads much better.

T.

 

[Robert Klemme]

That true. But at least it reads much better.

Even that is subjective: I personally prefer to read f.to_enumrange,
1, 5) because then I know this is going to be capable of all the
Enumerable methods. YMMD though.

Kind regards

robert

 

[James Edward Gray II]

Even that is subjective: I personally prefer to read f.to_enum
range, 1, 5) because then I know this is going to be capable of
all the Enumerable methods. YMMD though.

I agree. It's also worth noting that to_enum() is aliased to enum_for
() which I think often reads a little better.

James Edward Gray II

 

[Erwin Abbott]

Thanks for the replies. I hadn't looked at Enumerator before, I think
that will do the trick. I kind of agree it's not the prettiest looking
code, but I'll write my own #map, #to_a, etc and won't have to look at
it again.

I heard rumor that a future Ruby will ultimately pass thru each
parameters, but in the mean time you can have a go with Facets
enumerablepass.rb (http://facets.rubyforge.org).

I'll look into that too... I see quite a lot of people using facets in
the code and have been meaning to check it out. It seems like passing
parameters along would've been easy and very useful, I'm sort of
surprised it's not already that way.

Cheers,
Erwin

 

[Rick DeNatale]

I heard rumor that a future Ruby will ultimately pass thru each
parameters,

I'm not sure that that means in general, but what the current 1.9 does
is to first make Enumerator part of the standard library, and to make
each and other similar methods return an enumerator for the method and
it's parameters in cases where no block is given.

i.e. (in ruby 1.9)

e = "abc".each_byte
is equivalent to
e = "abc".enum_foreach_byte)

and
e = array.each_slice(2)
is equivalent to
e = array.enum_foreach_slice, 2)

and you can do things like:

"abc".each_byte.inject {|sum, chr| sum + chr}

 

[James Edward Gray II]

I'm not sure that that means in general, but what the current 1.9 does
is to first make Enumerator part of the standard library...

Enumerator is part of the standard library (libraries shipped with
Ruby) in Ruby 1.8. 1.9 mores the library to the core (no require
needed).

James Edward Gray II

 

[Trans]

Even that is subjective: I personally prefer to read f.to_enumrange,
1, 5) because then I know this is going to be capable of all the
Enumerable methods. YMMD though.

Not sure I understand what you mean by "because then I know this is
going to be capable of all the Enumerable methods", b/c what #range
returns can be too. In fact I think it can be defined like this:

def range(x,y)
Functor.new(self) do |op, obj|
obj.to_enum(op,x,y)
end
end

(don't quote me on that though, I haven't tested it.)

So I take it you actually mean that using to_enum is better in that
you don't need to know anything about #range to understand the code? I
can understand, but I think its preferable to break things down into
smaller, more readable, sub-functions.

T.

 

[Robert Klemme]

Thanks for the replies. I hadn't looked at Enumerator before, I think
that will do the trick. I kind of agree it's not the prettiest looking
code, but I'll write my own #map, #to_a, etc and won't have to look at
it again.

No, the point is that with Enumerator you do *not* have to write your
own #map etc. Just create a method that will iterate - whatever name -
and then *any* client can do

obj.to_enumyour_iterator_method, arg1, arg2).map {|item| item.to_s}

(see my first posting to the thread)

I'll look into that too... I see quite a lot of people using facets in
the code and have been meaning to check it out. It seems like passing
parameters along would've been easy and very useful, I'm sort of
surprised it's not already that way.

But then again, #each probably needs arguments less often than you might
think right now.

Kind regards

robert


PS: Please do not top post. Thank you!

 

[Rick DeNatale]

Enumerator is part of the standard library (libraries shipped with
Ruby) in Ruby 1.8. 1.9 mores the library to the core (no require
needed).

Thanks James, that's what I meant, of course. I plead one or more of:

1) Alzheimers
2) Arthritis
3) Brain f*rt.

 

[Robert Klemme]

Not sure I understand what you mean by "because then I know this is
going to be capable of all the Enumerable methods", b/c what #range
returns can be too.

Yes, it *can* - that's not the point. But if I see foo.to_enumbar,
24, 5) in code I know already that the return value of #to_enum includes
Enumerable while in the case of #range I have to look into documentation.

In fact I think it can be defined like this:

def range(x,y)
Functor.new(self) do |op, obj|
obj.to_enum(op,x,y)
end
end

(don't quote me on that though, I haven't tested it.)


So I take it you actually mean that using to_enum is better in that
you don't need to know anything about #range to understand the code?
Exactly.

I can understand, but I think its preferable to break things down into
smaller, more readable, sub-functions.

Um, I am not sure I understand what you mean by this in the current
context. Can you please elaborate?

Kind regards

robert

 

[Trans]

Yes, it *can* - that's not the point. But if I see foo.to_enumbar,
24, 5) in code I know already that the return value of #to_enum includes
Enumerable while in the case of #range I have to look into documentation.




Um, I am not sure I understand what you mean by this in the current
context. Can you please elaborate?

Hmmm... The best answer I can probably give is actually this:

http://thinking-forth.sourceforge.net/

Sorry it's not a concise answer, but this conversation could very well
EXPLODE from here. And I'd prefer to keep DRY ;-)

T.

 

[Robert Klemme]

Hmmm... The best answer I can probably give is actually this:

http://thinking-forth.sourceforge.net/

Sorry it's not a concise answer, but this conversation could very well
EXPLODE from here. And I'd prefer to keep DRY ;-)

Frankly, I won't be reading a 300+ page document in order to try to get
an idea of what you /might/ have intended.

Kind regards

robert