Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85297
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <550C317E.8020508@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>
Date: Fri, 20 Mar 2015 14:55:49 +0000
Message-ID: <CAAn=CzUV+qYcJmUinGDOGaDYODz2dgidG7HD-6VCEf_bm0La8w@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=001a11c37f9c1de9850511b9834d
Subject: Re: [PHP-DEV] RFC - Array slice syntactic sugar
From: bowersbros@gmail.com (Alex Bowers)

--001a11c37f9c1de9850511b9834d
Content-Type: text/plain; charset=UTF-8

>
> 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]
>

--001a11c37f9c1de9850511b9834d--