David Alan Black <dblack / candle.superlink.net> writes:

> On Thu, 22 Feb 2001, Dave Thomas wrote:
> 
> > David Alan Black <dblack / candle.superlink.net> writes:
> > 
> > > I guess h.each_with_index is, in effect, shorthand for
> > > h.entries.each_with_index, since the data structure that's being
> > > indexed is not the hash but the array returned by Hash#entries.
> > 
> > I think it could also be the other way around: each_with_index returns 
> > key/value pairs out of the hash, and #to_a performs an (artificial)
> > flattening on the hash into an array.
> 
> But what does each_with_index add, functionally, to Hash, given that
> we already have Hash#each?  What use is it for a hash to assign, in
> random order, numerical indices to its key/value pairs?  

each_with_index seems to me to be largely a convenience method,
whether applied to arrays or hashes.

> 
> I can't help wondering if this is a case where Enumerable is casting
> slightly too wide a net.  If implementing each_with_index were left to
> the mixing-in classes -- and then not implemented in Hash -- I wonder
> whether anyone using Hash would miss it.  (In this connection, note
> that Hash doesn't implement each_index.)

But... if people are suggesting a unification of Array and Hash, then
then would suggest a common interface, even in cases where it might
make less sense.

> > If we've saying that anything that can be indexed is an array, then I
> > guess we should include files, directories, strings, ...  Similarly is
> > we're saying that anything with keys is a Hash.
> 
> Not a Hash -- but perhaps Hashable, the name of my pet non-existent
> module :-) Maybe it should be called Keyable, so as not to make it too
> Hash-bound.  I see the keyedness of hashes and arrays, not as meaning
> that one of the two is the "real" one and the other a derivative, but
> as something they share.  In spite of the non-existence of the module,
> I find their common keyability (or whatever) as central and as
> compelling as their common enumerability -- which is why I keep coming
> back to it, I guess.

I can see that. There are collection libraries which that kind of
hierarchy, but the hierarchies tend to run deep:

   Collection -> Keyed Collection -> Unique Keyed Collection -> Hash
                                                            \-> Vector

or somesuch. Ruby seems to more pragmatic, in the "walks like a duck,
talks like a duck" sense. If you wanted to add (say) ISAM methods to
File, then you'd end up with a Keyable file, but would mixin in
Keyable give us anything? (That's not argumentative--I'm honestly not
sure).


Dave