Re: String not enumerable, what about IO? (was Re: Symbol < String in Ruby > 1.8)

On 10/21/06, [e-mail] <[e-mail]> wrote:
> I think that plural-noun names should return something that behaves in
> every possible way like a collection of the noun-items:
>
>    lines = string.lines
>    puts lines               # you see the lines themselves
>    lines[3] = "hi"          # you can index the collection
>    lines.select {|l| ... }  # iteration
>
> etc.  This could be a lazy array-like object, for efficiency.

I agree.

I would expect .lines to give me an object that contains the lines.
For a hash, I'd expect .keys to give me an object with all the keys
in, .values to give me an object with all the values in. For an array,
.elements might return all the elements. For a web page fetched via
HTTP, .cookies would return a collection containing the cookies,
.headers a collection of all the header lines from the HTTP
transaction. And so on.

The word "each" to me clearly implies "one at a time". If I'm washing
dishes and ask someone to hand me each plate, I don't expect them to
give me the whole lot in a stack. So I'd expect methods with "each" in
the name to either take a code block to apply to each object, or to
return an enumerator that will let me process each object myself.

Whether you call the methods .each_line, .each_element or just .each
is kind of a trivial issue to me. It depends on the collection class
in question, and whether there are likely to be multiple sensible ways
to iterate through it.

For instance, for an array-like collection I'd probably just define
.each. For a hash, I'd expect .each_key and .each_value.

Similarly, whether you want to overload the .each method to perform
both tasks (enumerator returner and code block executor), or have
separate methods with each in the name, is also kind of a trivial
issue for me. I don't see why you wouldn't want to overload, though.


mathew
-- 
<URL:http://www.pobox.com/~meta/>