On 10/20/06, dblack / wobblini.net <dblack / wobblini.net> wrote:

> On Sat, 21 Oct 2006, Yukihiro Matsumoto wrote:
...
> > |Did you see Austin's by_* methods?
> > |
> > |   string.lines   # an array
> > |   string.by_lines { }   # enumeration (no intermediate array)
> > |   string.by_lines       # enumerator (or your "something"?)
> > |
> > |I really like that way of breaking it out.
> >
> > Hmm, you think that "by_" means THAT much.
>
> It seems like a good way of namespace-splitting, so that arrays (my
> naive "collections" :-) don't have to compete with enumerators or
> enumerator-like entities.

Extending that logic do you also want, say:

   {:a => :b, :c => :d}.each_key => ERROR NO BLOCK GIVEN
   {:a => :b, :c => :d}.by_keys {|k|} ... enumeration
   {:a => :b, :c => :d}.by_keys  => Enumerator

And so on for the various each* method in the other classes in the
Core and standard library?

I think that the issue is different for each* and other methods with
names like lines, chars, bytes, etc.

And I don't see it as Arrays competing with Enumerators.  Arrays as
jack-of-all-trades collections are perhaps overused in Ruby.
Sometimes, when some of the features of Array either aren't needed or
are less efficient than the same features in other classes, it's good
to let our friend Array have a rest on the bench and bring in a
specialist.

Set is a good example, Arrays can be used a set with proper care, but
Set is often a better choice with a set is wanted.

And an Enumerator, when you look at it in a certain way, is a kind of
collection itself.


-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/