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

On 10/20/06, [e-mail] <[e-mail]> wrote:
> 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).

I don't really see the harm, as it doesn't seem incompatible with 1.8
usage since it was an error before for the most part, and I find
something like

   a_hash.each_key.map {...}

quite natural.

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

Yeah, but I like the new each* feature better.

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

I've sort of lost the thread here.  I think that I'd already agreed
that lines/chars/bytes should return an array or array-like thing.

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

Why do those method names have an overwhelming sense of returning an array?

To me they suggest that they return an collection, but why does that
collection need to be an array?

A collection of lines/chars/bytes yes, but not necessarily an array.
To my mind collections are things which have elements which can be
enumerable.   But collections aren't necessarily indexable, or finite,
or have a defined enumeration order for their elements.

So, to my mind, Enumerators really ARE collections, which don't
provide indexing.

In some cases, an array is the natural return type for these methods
from some objects. But there are cases where that isn't clear, or even
possible.  If we wanted to have lines, chars, and bytes methods for
IO, I don't think that it could return an array, since what's read
from an IO is in general unbounded, and random access can be either
problematical or very expensive.


One way to deal with this would be to not define those methods,
another would be to define them but to return an non-indexable
collection instead of an array. That non-indexable collection might
have a name which was named to invoke the notion of collection better
than Enumerator does, but it would look a lot LIKE an Enumerator.

Someone might argue that unbounded collections should be disallowed
because each wouldn't terminate, but I'd argue that this falls into
the same area as supporting loop..end, or while true ... end.

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

I