From: Dossy Date: 2002-07-07T11:14:52+09:00 Subject: Re: is there a better string.each? On 2002.07.07, Tom Sawyer wrote: > > indeed, they arn't matching. and it would be nice if we could come to a > general agreement about it. this all started with the notion that the > String#each method (and related methods) did not keep with POLS, unlike > the Array. so the comparison was drawn. I don't know Matz very well, but perhaps the reason why String#each iterates over whole newline-terminated strings is because you're asking for "each String" ... and a string isn't a character, it's a sequence of characters -- in Matz's least surprise, a sequence of characters terminated by a newline. So, perhaps an easy way to avoid backward-compatibility breakage and to ease into m17n, we simply define String#characters which returns an Array of Character -- which can be either single-byte, or multi-byte, depending on the appropriate encoding. Then, Character#each would Do The Right Thing and iterate over the array, one Character at a time. Then, as shorthand, String#each_character could do that same iterating for ease of use. But writing "foo".characters.each { ... } is just as clear, so I don't know if the shorthand #each_character would add any benefit. Actually, this could be implemented _today_ with no change to the core ... maybe I'll try implementing it as an experiment. Without encoding support/help in the core, it would probably have to be String#characters(Encoding) ... Has anyone already done this? Am I talking about reinventing the wheel, here? Of course, I've never designed a language that people other than myself and a few people ever used, so I don't have any idea how well this idea goes over with the "rest of you" out there ... Thoughts? -- Dossy -- Dossy Shiobara mail: dossy@panoptic.com Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70)