From: Austin Ziegler <halostatue@...>
Date: 2004-12-10T06:11:06+09:00
Subject: Re: [rcr] String#split behaves odd

On Fri, 10 Dec 2004 05:20:17 +0900, trans.  (T. Onoma)
<transami@runbox.com> wrote:
> On Thursday 09 December 2004 01:49 pm, Austin Ziegler wrote:
>>>> split. This change would break a lot of code silently.
>>> Really? In all my code I either had to put the -1 in b/c I was
>>> getting unexpected results (wasting many hours, btw!); or it
>>> didn't really matter either way --empty strings usually end up
>>> in no-effect results.
>> Really. I just did a quick audit of my publicly released code --
>> no checks to see what would be broken if I add -1 -- but NONE of
>> my code uses split with -1, and I have ~45 split calls in said
>> code. Are YOU going to volunteer to test all of my code (and
>> everyone else's?) because you don't like adding the -1?
> Could you send me said code? I would like to see how it effects
> things.

No; it's all publicly available, as I said. TeX::Hyphen,
Text::Format, Ruwiki, Diff::LCS, Archive::Tar::Minitar, etc. Of all
of these, I think that I saw one of them that would probably benefit
from using -1 (and that's a command-line program in Diff::LCS).

> Also understand that I never paid _any_ attention until one day my
> program wouldn't work and I could not figure out why. Well, nearly
> a day of debugging later I traced it to a split call and finally
> learned about the -1. I was not amused.

Again, *shrug*. I think that I've had to use the -1 form of #split
exactly once in any code that I've written for Ruby.

>>> Might it break code? Sure. But a lot? I doubt it. In fact I
>>> suspect some of those same programs might have edge cases that
>>> would break them for the lack of the -1.
>> *shrug*
>>
>> My code is written without the -1. If you want this default
>> behaviour changed -- that's been in Ruby for quite a while --
>> then you take on the responsibility for testing all of the code
>> out there.
> In the same amount of time I spent working out that first bug, I
> probably could have adjusted the vast majority of programs that
> would be effected.

Probably not. Remember that when you're talking about changing a
default, you're talking about a lot of programs -- and a lot of
legacy programs. If you instead suggest:

  class String
    def splitall(re)
      self.split(re, -1)
    end
  end

I'll support you. I will NOT support you changing default behaviour
on something that is as widely used as split.

>> It is not clear that the existing behaviour is broken.
> Broken is not the argument. Obviously it is usable. The question
> is, is it well designed?

IMO, it's a little late to be asking that.

>      If the _limit_ parameter is omitted, trailing null fields are
>      suppressed. If _limit_ is a positive number, at most that
>      number of fields will be returned (if _limit_ is +1+, the
>      entire string is returned as the only entry in an array). If
>      negative, there is no limit to the number of fields returned,
>      and trailing null fields are not suppressed.
> 
> Just reading that is enough to know, but also given that the issue
> has come up a number of independent times, it is quite obvious
> that it is not well designed.

i don't think it's come up all that often, and I don't think it's an
issue all that often.

-austin
-- 
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca