Is there a better string.each?

ruby-talk
41

As I’ve said before, this is a nice solution, Hal. However, I would
expect
that native support for this would be faster, and when one is itterating
over characters, speed can quickly become an issue. I was hoping for
something faster than split(‘’), which is also not very memory efficient,
creating an arbitrary Array object in the process.

Sorry, I guess I missed something. I didn’t
realize that performance was an issue in this
discussion.

On a side note: As a rule, I think it’s better
to write “interim” code in Ruby (and experiment
with it) before changing the core. That’s not
to say that such a change is precluded forever.

Hal Fulton

···

----- Original Message -----
From: “Sean Russell” ser@germane-software.com
Newsgroups: comp.lang.ruby
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Monday, July 08, 2002 11:05 PM
Subject: Re: is there a better string.each?

42

Sean Russell wrote:

As I’ve said before, this is a nice solution, Hal. However, I would expect
that native support for this would be faster, and when one is itterating
over characters, speed can quickly become an issue. I was hoping for
something faster than split(‘’), which is also not very memory efficient,
creating an arbitrary Array object in the process.

… and

def each_char
self.each_byte {|b| yield b.chr }

does not work with multibyte chars, noo?

Tobi

···

–
http://www.pinkjuice.com/

43

Hi –

Hal E. Fulton wrote:

Better perhaps to try it in Ruby awhile
fbefore making an RCR:

class String
def chars
self.split(“”)
end
def each_char
self.each_byte {|b| yield b.chr }
end
end

As I’ve said before, this is a nice solution, Hal. However, I would expect
that native support for this would be faster, and when one is itterating
over characters, speed can quickly become an issue. I was hoping for
something faster than split(‘’), which is also not very memory efficient,
creating an arbitrary Array object in the process.

I think part of the original #chars idea was that it would return an
array of the characters, as well as iterating over them. The version
I posted a few posts back was:

class String
def chars
split(“”).each {|c| yield c if block_given?}
end
end

(which really doesn’t do much other than relocate the #each from the
caller to the body of the method, but that’s what people seemed to
want :slight_smile:

David

···

On Tue, 9 Jul 2002, Sean Russell wrote:

–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav

44

Try this again:

Thanks, for the patch

Guy Decoux

45

Sorry, I guess I missed something. I didn’t
realize that performance was an issue in this
discussion.

I don’t think the main thrust was performance. It’s just that the split
approach is potentially expensive memory-wise (for large strings).
Obviously, it would be nice to have a mechanism that both worked and was as
efficient as possible.

… Which I think is to have an each_char iterator, as Matz has said will be
in 1.8, and which anyone who has written more than twenty lines of Ruby can
whip up for themselves in the interim.

On a side note: As a rule, I think it’s better
to write “interim” code in Ruby (and experiment
with it) before changing the core. That’s not
to say that such a change is precluded forever.

Amen. It would be sad to end up having to release a 1.8.1 five minutes later
… but, of course, I’d never expect Matz to make that mistake !!

Harry O.