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, dblack / wobblini.net 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.