> > So $dictionary['elephant':'snake'] returns all elements with keys which > sort lexically between 'elephant' and 'snake', regardless of whether the > array is sorted.
Makes sense to me. Alternatively, a key-based slice could look up the position in the array of > the two keys, and then perform a positional slice between those positions, > i.e. $array[$a:$b] == $array[ @ key_position($array, $a) : > key_position($array, $b) ]. I'm not sure that's particularly intuitive or > useful, but again, it has no problem with string keys. I'd say no to that, since it is not an obvious use case, since if you are defining associated arrays, going for the indexes of those fields feels strange; since one of the major benefits to associated keys is that the order doesn't matter anymore. Having this one feature order dependant whilst using the associated keys isn't correct in my view. On 20 March 2015 at 14:41, Rowan Collins <rowan.coll...@gmail.com> wrote: > Alex Bowers wrote on 20/03/2015 13:40: > >> Still not sure how we can implement a range of strings. But since thats >> for a different feature, I'll leave that issue for now. >> > > I can't resist a quick answer: if you can define a key-based slice at all, > you can define it for both integer and string keys. Bear in mind the a:b > here isn't a range, it's just a pair of values specifying which items to > include in the slice. > > If the definition of a key-based slice is "all elements whose key > satisfies $key >= $a && $key <= $b", then you're just doing comparisons > between strings, which are defined as lexical order. So > $dictionary['elephant':'snake'] returns all elements with keys which sort > lexically between 'elephant' and 'snake', regardless of whether the array > is sorted. > > Alternatively, a key-based slice could look up the position in the array > of the two keys, and then perform a positional slice between those > positions, i.e. $array[$a:$b] == $array[ @ key_position($array, $a) : > key_position($array, $b) ]. I'm not sure that's particularly intuitive or > useful, but again, it has no problem with string keys. > > Regards, > -- > Rowan Collins > [IMSoP] >
