On Thursday 09 December 2004 04:11 pm, Austin Ziegler wrote:
| 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).

Okay, well that's good enough. I'll grab a couple and check it out.

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

Once is all it took for me to pull my hair out for a day ;)

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

Well, not be hand. I would use a supporting script. Nontheless it not like I 
will actually be doing this.

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

Well, that is a fair compromise I think.

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

What if it turns out, for example, that expirementation shows approx. 95%+ of 
code would continue working unaffected? Obviously we don't know either way. 
But I wouldn't be so quick to rule out the possibility.

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

On the whole, perhaps, not that often. But presently it has been twice in that 
last month. And if we don't work on improving things at times such as these, 
when might we ever?

T.