[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

using Enumerable when each has arguments?

Erwin Abbott

5/21/2007 10:42:00 AM

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
15 Answers

Robert Klemme

5/21/2007 10:57:00 AM

0

On 21.05.2007 12:41, Erwin Abbott wrote:
> 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_enum(:each,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

5/21/2007 1:27:00 PM

0



On May 21, 6:41 am, "Erwin Abbott" <erwin.abb...@gmail.com> wrote:
> 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.rub...).

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

5/21/2007 2:35:00 PM

0

On 21.05.2007 15:27, Trans wrote:
>
> On May 21, 6:41 am, "Erwin Abbott" <erwin.abb...@gmail.com> wrote:
>> 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 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.rub...).

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

5/21/2007 3:52:00 PM

0



On May 21, 10:35 am, Robert Klemme <shortcut...@googlemail.com> wrote:

> > 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. :-)

That true. But at least it reads much better.

T.

Robert Klemme

5/21/2007 3:55:00 PM

0

On 21.05.2007 17:51, Trans wrote:
>
> On May 21, 10:35 am, Robert Klemme <shortcut...@googlemail.com> wrote:
>
>>> 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. :-)
>
> That true. But at least it reads much better.

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. :-)

Kind regards

robert

James Gray

5/21/2007 4:00:00 PM

0

On May 21, 2007, at 10:55 AM, Robert Klemme wrote:

> On 21.05.2007 17:51, Trans wrote:
>> On May 21, 10:35 am, Robert Klemme <shortcut...@googlemail.com>
>> wrote:
>>>> 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. :-)
>> That true. But at least it reads much better.
>
> 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

5/21/2007 5:42:00 PM

0

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.rub...).

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

On 5/21/07, James Edward Gray II <james@grayproductions.net> wrote:
> On May 21, 2007, at 10:55 AM, Robert Klemme wrote:
>
> > On 21.05.2007 17:51, Trans wrote:
> >> On May 21, 10:35 am, Robert Klemme <shortcut...@googlemail.com>
> >> wrote:
> >>>> 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. :-)
> >> That true. But at least it reads much better.
> >
> > 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
>
>

Rick DeNatale

5/21/2007 5:47:00 PM

0

On 5/21/07, Trans <transfire@gmail.com> wrote:


> 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_for(:each_byte)

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

and you can do things like:

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


--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denh...

James Gray

5/21/2007 5:52:00 PM

0

On May 21, 2007, at 12:46 PM, Rick DeNatale wrote:

> On 5/21/07, Trans <transfire@gmail.com> wrote:
>
>
>> 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...

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

5/21/2007 5:52:00 PM

0



On May 21, 11:55 am, Robert Klemme <shortcut...@googlemail.com> wrote:
> On 21.05.2007 17:51, Trans wrote:
>
>
>
> > On May 21, 10:35 am, Robert Klemme <shortcut...@googlemail.com> wrote:
>
> >>> 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. :-)
>
> > That true. But at least it reads much better.
>
> 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. :-)

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.