[ruby-talk:03616] Re: A small quiz -- str[n] vs str[n,1] nearing resolution?

Hi,

"Dave Thomas" writes:
> [e-mail] (Yukihiro Matsumoto) writes:
>
> > No, no.  I'd happy to change the behavior, provided if:
> >
> >   (a) gain and loss are clarified.
> >   (b) incompatibility damage estimate is done.
> >
> > I guess few programs would be affected by this change.

That is good news.

> > So the point
> > should be clarification.

OK.

I certainly think that the more leftover counterintuitive oddities (or
Perl-like idiosyncrasies :-) that we can eliminate now, the better it will
be for Ruby and Ruby users in the long run, IMHO.

> Well, the PLS would suggest that str[n] should return nil when
> str[n,1] does, and vice versa.

Does everyone agree on this?

> Returning nil at the end would also eliminate a source of errors

And thus also make Ruby easier to learn, remember, teach, and use. A good
competitive advantage.

>   count = 0
>   str = "hello"
>   count += 1 while str[count]
>   puts "Size = #{count}"        #=> 5
>
>   count = 0
>   str = "hello"
>   count += 1 while str[count, 1]
>   puts "Size = #{count}"        #=> 6
>
>
> I can't speak to the risks - I don't know how many people have relied
> on the existing behavior (although I can't imagine it's very many, as
> the behavior doesn't seem intuitive).

Well, given imperfect human memory and the inability to effectively poll
every Ruby user out there, there is probably no reasonably effective way to
determine this. However, perhaps the most important cases to consider are
those of Ruby code in the standard library and Ruby code in the RAA. If this
change didn't break any such tests, it would be at least half-way reassuring
(and probably somewhat more so, given Matz's guess above); otherwise we
would at least have some indication of how strongly we should want to put
off this change until Ruby 3000.

Here is where some previously discussed issues of test cases and test case
standards show their importance. :-)

Conrad