Re: RCR allow indexing last n items

On 31/12/2007, David A. Black <[e-mail]> wrote:
> Hi --
>
> On Mon, 31 Dec 2007, Michal Suchanek wrote:
>
> > On 31/12/2007, David A. Black <[e-mail]> wrote:
> >> I think it's a matter of defining what it means to start taking a
> >> substring at a non-existent point. As it now stands, you can never do
> >> that, whether the way you reach that non-existent point is with a
> >> positive or negative index:
> >>
> >>>> str = "abc"
> >> => "abc"
> >>>> str[4..10]
> >> => nil
> >>>> str[-4..-1]
> >> => nil
> >>
> >> Starting at a non-existent point is not the same as *stopping* at that
> >> point. In other words, this is meaningful:
> >>
> >>>> str[0..10]
> >> => "abc"
> >>
> >> because you're starting in the string, at a defined point, and going
> >> as far as you can. The problem with str[-4..-1] is not how far it
> >> goes, but the fact that it doesn't start in the string. At least,
> >> that's what makes it feel to me like it's not just the mirror case of
> >> the positive one.
> >
> > It's just a matter of point of view. You advocate the point of the
> > string implementation which always counts from the start of the string
> > but I am advocating the view from the interface side that pretends to
> > count from the end. And that's what the people using ruby see.
>
> I don't mean the start of the string; I mean the starting index, into
> the string, of the first character you want. If it's -10 on a
> 3-character string, then it's an index that's out of range.
>
> I guess you could look at it by saying there's no starting point;
> there's just n characters, with leading or trailing non-existent ones
> chopped off. I'm just not sure I like the semantics of having str[-10]
> be nil, but str[-10..anything] being a string.
>
no, it's not -10..anything, it's -10..anything as long as it defines a
part of the string.

Let me explain on a higher level:

a..b defines can be interpreted as an interval

* when used fo indexing a collection the collection length is added to
any negative border

In terms of intervals the collection is present inside interval 0...n

The rules for indexing are as follows:

* if a is not in 0...n return nil
* if a>b return ""
* return intersection of 0..n and a..b

This mans that there might be an intersection but the rules are
defined in different terms and would not return it. I propose to chnge
the rules to

* if a>b return ""
* if there is no intersection return nil
* return intersection of a..b and 0..n

Of course, this is the minimal change. It only allows returning
intersections that vere previously invalid because a was outside 0..n
(a < 0) but does preserve the old semantic as much as possible.

There is another semantic that is somewhat weird: if the interval is
invalid (a>b) the returned value is "" but when a is outside 0..n the
return value is nil. In some cases both is true but only one of the
values can be returned.

Thanks

Michal