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

Hi --

On Tue, 24 Oct 2006, Rick DeNatale wrote:

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

We're going in circles at this point; see my earlier posts.


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