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

Hi --

On Sat, 21 Oct 2006, Rick DeNatale wrote:

> On 10/20/06, [e-mail] <[e-mail]> wrote:
>
>> On Sat, 21 Oct 2006, Yukihiro Matsumoto wrote:
> ...
>> > |Did you see Austin's by_* methods?
>> > |
>> > |   string.lines   # an array
>> > |   string.by_lines { }   # enumeration (no intermediate array)
>> > |   string.by_lines       # enumerator (or your "something"?)
>> > |
>> > |I really like that way of breaking it out.
>> >
>> > Hmm, you think that "by_" means THAT much.
>> 
>> It seems like a good way of namespace-splitting, so that arrays (my
>> naive "collections" :-) don't have to compete with enumerators or
>> enumerator-like entities.
>
> 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).

>  {:a => :b, :c => :d}.by_keys {|k|} ... enumeration
>  {:a => :b, :c => :d}.by_keys  => Enumerator
>
> And so on for the various each* method in the other classes in the
> Core and standard library?

Possibly, but possibly not: I'd want Matz to decide for each case.

(What ever happened to to_enum or enum_for?  Some overt reference to
Enumerators [which seems reasonable, if they're there] might take some
of the pressure off all the naming stuff.)

> I think that the issue is different for each* and other methods with
> names like lines, chars, bytes, etc.

I do too.

> 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.

> Sometimes, when some of the features of Array either aren't needed or
> are less efficient than the same features in other classes, it's good
> to let our friend Array have a rest on the bench and bring in a
> specialist.
>
> Set is a good example, Arrays can be used a set with proper care, but
> Set is often a better choice with a set is wanted.
>
> And an Enumerator, when you look at it in a certain way, is a kind of
> collection itself.

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.)


David

-- 
                   David A. Black | [e-mail]
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