Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85298
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAn=CzUV+qYcJmUinGDOGaDYODz2dgidG7HD-6VCEf_bm0La8w@mail.gmail.com>
References: <CAAn=CzWySWQU1D93WA7L2eHvd31zogekEHmDUOsN7P6kBK4VrA@mail.gmail.com>
	<550B5A81.1090706@gmail.com>
	<CAAn=CzUZPo=Yy79pRbot58nSR_tFqKYpd53kaAMbfxyUvz9Lwg@mail.gmail.com>
	<550B7189.4040608@gmail.com>
	<CAAn=CzUQc-av2dVBKwQg5xsCDiUXszfP1fWKVpBRMFNA3SjYEA@mail.gmail.com>
	<7486C296-7535-4633-AFE2-02E7BBC67BC5@gmail.com>
	<CAAn=CzXR=cU8Pq4wzNQXKLhqDt9WOF3CJfk2B=3z8DBtQhVvCg@mail.gmail.com>
	<550C1176.9050307@gmail.com>
	<CAAn=CzWzKXSW0m+CrjzAT+Lq-j07M_V-WnBAvwSDhqLKCo=OiA@mail.gmail.com>
	<550C1AE4.8090607@gmail.com>
	<CAAn=CzXoEwOnSZ+uVgAZMmdT4hxLSoiQWb9fYVs4XJbp2AJnpA@mail.gmail.com>
	<550C1EC3.8000106@gmail.com>
	<CAAn=CzXwPH-PnKg9tgFqcrU0k_iKPjDzMPqu6TtGKJCyFPCQ=w@mail.gmail.com>
	<550C317E.8020508@gmail.com>
	<CAAn=CzUV+qYcJmUinGDOGaDYODz2dgidG7HD-6VCEf_bm0La8w@mail.gmail.com>
Date: Fri, 20 Mar 2015 15:10:17 +0000
Message-ID: <CAPwsocEuhUK5yzzfXhEwUh=-fgkd6TXZCeVPHcf5oyLUsooaqA@mail.gmail.com>
To: Alex Bowers <bowersbros@gmail.com>
Cc: internals@lists.php.net, Rowan Collins <rowan.collins@gmail.com>
Content-Type: multipart/alternative; boundary=001a1136b574d964240511b9b661
Subject: Re: [PHP-DEV] RFC - Array slice syntactic sugar
From: leight@gmail.com (Leigh)

--001a1136b574d964240511b9b661
Content-Type: text/plain; charset=UTF-8

On Mar 20, 2015 2:59 PM, "Alex Bowers" <bowersbros@gmail.com> wrote:
>
> >
> > 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.collins@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]
> >

IMHO, stick to offsets in the first instance, this is a slice notation,
first order of business is to make it behave like array_slice (+on
strings). Assoc key based slicing feels pretty wrong to me at this point.

--001a1136b574d964240511b9b661--