Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85255
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.177 as permitted sender)
Message-ID: <550B7189.4040608@gmail.com>
Date: Fri, 20 Mar 2015 01:02:01 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAAn=CzWySWQU1D93WA7L2eHvd31zogekEHmDUOsN7P6kBK4VrA@mail.gmail.com>	<550B5A81.1090706@gmail.com> <CAAn=CzUZPo=Yy79pRbot58nSR_tFqKYpd53kaAMbfxyUvz9Lwg@mail.gmail.com>
In-Reply-To: <CAAn=CzUZPo=Yy79pRbot58nSR_tFqKYpd53kaAMbfxyUvz9Lwg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC - Array slice syntactic sugar
From: rowan.collins@gmail.com (Rowan Collins)

On 19/03/2015 23:55, Alex Bowers wrote:

> Thats a good point, something else that just came to me; your example 
> of $countdown[0:0]; if we had it as inclusive indexes, then this would 
> actually give you ['Five!', 'Five!'], which is unlikely to be what was 
> desired.

I'm not sure why it would duplicate the item like that. My 
interpretation of $array[$start:$end] would be "an array containing all 
those elements of $array with a position more than or equal to $start, 
but less than or equal to $end" ($position >= $start && $position <= $end).

Under that interpretation, $array[0:0] is a valid slice, of length 1, 
which would contain only the element of $array with position 0 (0 >= 0 
&& 0 <= 0).

Since you propose to preserve keys in the slice, it's actually 
impossible to have a duplicate item in the output anyway: if you were 
right and it selected the first item twice, you'd get [5 => 'Five!', 5 
=> 'Five!'], but keys are unique by definition, so it would end up 
stored as [5 => 'Five!'].


> 1) The range cannot be 0 in length (such that, from - to must be > 0) 
> - This would also get around issues of people trying to use it like so 
> : $countdown[5:3], as the expected outcome of that should be a fatal 
> error.

$countdown[0:0] is a slice of length 1, not 0, just as $countdown[0:1] 
is a slice of length 2, not 1. Under my proposed definition, 
$countdown[5:3] could simply always return an empty array, since there 
is no value of $position such that ($position >= 5 && $position <= 3).


> Also, your use-case of 0:0 would be better placed simply using 
> $countdown[0].

Check my example again. $countdown[0] refers to the element with key 0, 
so is absolutely not a replacement for $countdown[0:0]. This is the 
whole point of my example.



> I think the use of the @ symbol would be misplaced for this

To be clear, @ was just the first idea that came to mind, not central to 
my point. The point is to first create syntax for "positional access", 
and then extend that to "positional slice access".


> A different symbol is certainly a possibility; but this is something 
> that happens nowhere else (ignoring the & by reference) in PHP, and 
> feels like it isn't the best solution to the problem.

I'm not sure what you mean by "something that happens nowhere else" PHP 
has syntax for all sorts of things, using all sorts of symbols. Your own 
suggestion uses the : symbol in a place where it currently can't exist.


> Other languages that implement this do not require a prefixed symbol, 
> and I don't see the need for PHP to have one.

Most languages don't need to worry about an "array" type which has keys 
independent from their position. PHP is the only language I know where 
the 0 in $foo[0] does not refer to the position in the array, but a key 
which can appear at any position.


> 2) Would a possible solution to this be just to make it explicitly 
> clear in the documentation that this *does not* refer to the keys, and 
> instead the array positions?

To my mind, no. Manual pages about syntax features are hard to find 
unless you know exactly what that syntax feature is called, and 
documenting an inconsistency is no substitute for avoiding that 
inconsistency in the first place.

Regards,

-- 
Rowan Collins
[IMSoP]