From: Eric Mahurin <eric_mahurin@...>
Date: 2005-09-28T01:13:01+09:00
Subject: Re: Class and Iterator Design Question

Don't you want peas in a pod and not the other way around :)

I think either is fine with a couple changes:

alternative #1: in the docs say that #pods returns an
Enumerable not an Array.  This gives you the freedom to change
the implementation to use a Set or some other Enumerable to
hold the pods.

alternative #2: as long as you don't have multiple each
methods, call the method #each instead of #each_pod and include
Enumerable.

--- Jim Freeze <jim@freeze.org> wrote:

> This may be a silly design question, but I always balk at
> the right answer when I am confronted with it.
> 
> I have a class that manages a list and users need to iterate
> over that list.
> The way I see it, I have to basic alternatives:
> 
>   # Give user access to the array and let them iterate over
> Array
>   class Pea
>     attr_reader :pods
>   end
>   Pea.new.pods.each { |pod| ..do stuff.. }
> 
> or
> 
>   # Provide a custom iterator
>   class Pea
>     def each_pod
>       @pods.each { |pod| yield pod }
>     end
>   end
>   Pea.new.each_pod  { |pod| ..do stuff.. }
> end
> 
> In other words, for classes that manage a list of items,
> do people prefer to see a custom iterator, such as
> #each_<item>,
> or do they prefer getting back an array and iterating
> over it themselves, such as #<items>.each?
> 
>   Pea.new.each_pod  { |pod| ..do stuff.. }
>   Pea.new.pods.each { |pod| ..do stuff.. }
> 
> Cheers
> --
> Jim Freeze
> 
> 



		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com