From: "David A. Black" <dblack@...>
Date: 2005-05-22T23:18:27+09:00
Subject: Re: join not in Enumerable

Hi --

On Sun, 22 May 2005, Eric Mahurin wrote:

> --- "David A. Black" <dblack@wobblini.net> wrote:
>> I have to say, though, that I think #each_with_index should
>> be removed
>> from Enumerable and pushed down to the classes that mix it in
>> (similarly to #each_index).  But I suppose as long as they
>> are called
>> "enumerable" they are in some sense associated with a
>> numerical index.
>
> Unfortunately for Hash, this can cause confusion to what an
> "index" is.  If it weren't for an already existing Hash#index
> (which gets a key), I would suggest it be brought over from
> Array to Enumerable.

I see it the other way.  "Index" means different things to different
enumerables.  I don't like the idea of having Enumerable define index
as consecutive integers slapped onto the elements.  I'd rather defer
that to the classes -- as, indeed, it is, with the strange exception
of each_with_index.

> I do tend to think that many of the Array methods should be
> brought over to Enumerable.  You could bring over just about
> any one that is non-modifying and operates sequentially forward
> on the array, but you may also restrict the ones related to an
> "index":
>
> *, +, <=>, ==, assoc, compact, concat, empty?, eql?, first,
> flatten, hash, join, last, length, nitems, pack, rassoc, size,
> to_s, uniq

Some of these would fare better than others.  #flatten has no general
meaning for an enumerable, since not all of them are recursive
container objects.  I don't think you can #pack an arbitrary
enumerable either.  #size also doesn't work for enumerables in
general, partly because some of them have no particular size and
partly because even for those that do, taking the size might cause
side-effects (e.g., an I/O-based enumerable).

In general, I think the design is a good one: Enumerable contains the
most common methods (plus each_with_index :-) and specialized behavior
is left to the classes.  Arrays provide a kind of normalized
representation through which some of those behaviors can be achieved
-- i.e., with #to_a you can hook into a lot of them.  Finer
granularity would certainly be possible; there's been discussion, for
example, of separating Iterable (or something like that) out of
Enumerable.


David

-- 
David A. Black
dblack@wobblini.net