Hi --

On Fri, 20 Oct 2006, Michael Selig wrote:

> ----- Original Message -----
> From: <dblack / wobblini.net>
>
>>> What I would prefer (and this would probably be a major change to the
>>> implementation) is to be able to treat ALL enumerable classes as Arrays.
> In
>>> other words, I'd like to suggest that Array and Enumerable effectively
> be
>>> the same thing, and that "Array" would be the superclass instead of
>>> "Enumerable".
>>
>> Enumerable isn't a superclass; it's a module.  Don't forget you can
>> mix it in to your own classes, so it's not just a matter of the
>> behavior of Ruby core classes that are Enumerable.
>>
>> Also, in some respects Array is the common currency of Enumerables, in
>> the sense that a lot of Enumerable methods return arrays.  But that
>> doesn't mean that Array itself is more Enumerable, so to speak, than
>> other Enumerable classes.
>
> I take your point about Enumerable being a module. I guess I said it badly,
> but I am trying to reconcile the way an Array works with that of an
> arbitrary Enumerable. They are similar, yet (at times) frustratingly
> different.
>
> 1) There are several methods in Array which I think could (should?) also be
> in Enumerable (eg: uniq, +, | etc).
>
> 2) Presumably, as an alternative to most of the Enumerable methods, you
> could use "to_a", and then use Array methods. I guess the Enumerable methods
> would be more efficient than doing this, so is that the reason for using
> them, or is it brevity or something else?

I think it's because they're not arrays, and not particularly
array-like in their native form.  Maybe some of them are -- but the
nice thing is that it doesn't have to be decided up front.

> 3) It has been mentioned before that Enumerable is a collection, which is
> unordered (ie: you can't index them). However characters or lines in a
> string or file *are* ordered. When you iterate over them you expect them to
> come back in order.
>
> 4) Other posts proposed having String#lines & String#bytes return an Array,
> so the same efficiency comment as (2) applies. They could also return an
> Enumerable object, which maybe more efficient but this relies on "each"
> returning them in order (which it probably would!).
>
> What I was getting at is that much of the time Enumerables *are* ordered,
> whether we need it or not. If we accept this, it makes sense, for example,
> to make things like "reverse" an Enumerable method.
>
> So why not make Enumerables indexable also? Presumably the base method would
> have to define the "[]" method to do this, but it would be sort of nice to
> efficiently index the n'th line in a string or m'th record in a file using
> Array style syntax without having to convert the whole thing to an array.
> You could even go the whole hog, and use "[]=" to make virtually all the
> Array methods available (delete, insert etc). May be a new module, rather
> than polluting Enumerable?
>
> Does that make sense?

I think it puts constraints on the idea of being enumerable, based on
one particular enumerable class (Array).  (I'm thinking not only about
the enumerable classes already in Ruby, but about Enumerable as a
programmer tool for use in new classes.)  It may be that arrays are
the most common enumerables, but we're not operating under a mandate
to elect the most popular one and replace Enumerable with it :-)  You
mention things that "probably" happen -- and that's fine, but, again,
there's no reason to go for a winner-take-all code reorganization
where enumerable classes that aren't array-like are viewed as
exceptional or unidiomatic.

I do think that there's room to adjust and fine-tune how Enumerable
works, but I wouldn't want to go in the direction of subordinating it
to Array.


David

-- 
                   David A. Black | dblack / wobblini.net
Author of "Ruby for Rails"   [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB's Weblog)        [2] | Co-director, Ruby Central, Inc.   [4]
[1] http://www.manning.com/black | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com    | [4] http://www.rubycentral.org