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

Hi,

In message "Re: String not enumerable, what about IO? (was Re: Symbol < String in Ruby > 1.8)"
    on Sat, 21 Oct 2006 11:29:21 +0900, [e-mail] writes:

|> Extending that logic do you also want, say:
|>
|>  {:a => :b, :c => :d}.each_key => ERROR NO BLOCK GIVEN
|
|Yes.  I don't like each* without a block (but I think I'm fighting a
|losing battle).

I am (sort of) with you for this issue though.

|> And I don't see it as Arrays competing with Enumerators.  Arrays as
|> jack-of-all-trades collections are perhaps overused in Ruby.
|
|I mean specifically that there seems to be a winner-take-all
|competition for the lines/chars/bytes/* (plural objects) namespace.

Can you rephrase?  I didn't get your intention here.

|Yes -- so let's have methods that sound like they're returning
|Enumerators :-) I don't want arrays to have a rest when the
|overwhelming thrust of the method-name semantics is array-like.  I'm
|not looking forward to seeing (or writing, for that matter) book
|passages like this:
|
|   You'd think that calling lines would give you all the lines in the
|   string, stored in a collection that you can print, inspect, and/or
|   index.  However, Ruby actually performs a kind of interception: what
|   you get is not an ordered collection of lines, but a kind of handle
|   on the collection that lets you perform some, but by no means all,
|   of the operations you might expect.
|
|etc.  (And this isn't just a "let's keep it simple for nubies" thing.)

Calling lines gives you lines in the strings contained in an object,
which happens to be an Enumerator now.  I don't think I get your
point.  What is your point among the following?

  * lines should return an array (not anything else)
  * lines should split a string into lines eagerly.
  * lines should not take an block.
  * an enumerator is not good enough for lines, more array-like object
    will do (even if it evaluates lazily).

I personally don't care if lines evaluate lazily.  That's perhaps
because I read the book on Haskell recently.

							matz.