On Tue, Oct 17, 2006 at 05:14:09AM +0900, James Edward Gray II wrote:
> On Oct 16, 2006, at 3:06 PM, Rick DeNatale wrote:
> 
> >I'm curious as to why it's a good thing to make String nonenumerable
> >and remove String#each instead of just aliasing lines to each?  Are
> >there drawbacks which make it worthwhile breaking existing code?
> 
> Well, now that we're stepping into the M17N world it no longer makes  
> sense to work with Strings until we specify a unit for the content.   
> Each what?  Each character, line, or byte?
> 
> I really think this is a good move.  Every book that introduces  
> String#each says something like, "You probably don't expect this, but  
> Strings iterate over lines..."  Now it will always be crystal clear:
> 
>   my_str.chars.each { ... }

Does this break duck-typing of String, IO, and Array?

I have libraries that take an object that they expect to respond to
#each, yielding each line.  That object can be an Array of strings, a
String, an IO, or some other kind of "source" object (useful to write a
tiny object that filters the lines before yielding them, maybe do utf-16
to utf-8 conversion, for example). I don't have to do any checking of
the class of the input object, I just document how it has to "quack":

  #each should yield each line of the input

I haven't looked at 1.9, does #each for IO still break at each line? Or
is IO also no longer enumerable, and you have to do:

  my_io.chars.each { ...} # used to be #each_byte
  my_io.lines.each { ...} # used to be #each

?

The same arguments about "unit of content" applies to IO, of course, so
I would expect this.

Even if IO does support #lines, I will have to either rewrite my code to
have a case based on the input object class, or perhaps a responds_to?
for #lines.

Sam

Btw, I'm assuming that #lines returns an Enumerable, not an Array,
because exploding a string into an Array of all its constituent lines
in-memory at once would be kindof heavy.