From: mathew Date: 2006-10-25T04:05:40+09:00 Subject: Re: String not enumerable, what about IO? (was Re: Symbol < String in Ruby > 1.8) On 10/21/06, dblack@wobblini.net 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 --