Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85241
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <550B39AA.2090706@garfieldtech.com>
References: <CAAn=CzWySWQU1D93WA7L2eHvd31zogekEHmDUOsN7P6kBK4VrA@mail.gmail.com>
	<550B39AA.2090706@garfieldtech.com>
Date: Thu, 19 Mar 2015 21:06:54 +0000
Message-ID: <CAAn=CzVvCGJeVQHMMqRWMRAwj6D8nTxWGArF3TS-PKoa4iX3og@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=001a1134676a5b26de0511aa94bb
Subject: Re: [PHP-DEV] RFC - Array slice syntactic sugar
From: bowersbros@gmail.com (Alex Bowers)

--001a1134676a5b26de0511aa94bb
Content-Type: text/plain; charset=UTF-8

I've had a quick scan of the list at https://wiki.php.net/rfc but cannot
seem to find anything. I'll read more carefully through, or is there a
different list elsewhere which I should look at?


On 19 March 2015 at 21:03, Larry Garfield <larry@garfieldtech.com> wrote:

> On 3/19/15 3:49 PM, Alex Bowers wrote:
>
>> This email is just to gauge the response for some syntactic sugar to be
>> added to PHP in regard to slicing an array.
>>
>> My proposal is something similar to Pythons slice, in PHP this would look
>> like:
>>
>> $slided = $array[1:4]
>>
>> This will get the elements in positions 1,2,3,4. (1 through 4 inclusive),
>> ignoring the actual key of the array. The result for an array will be an
>> array with the keys preserved, in the same order. Any multi-dimensions are
>> also respected and returned within the array.
>>
>> This is the same as using the array_slice method with the PRESERVE KEYS
>> fourth parameter passed through as true.
>>
>> The result for a string is the string from the two positions indicated.
>> This is the same as using substr().
>>
>> The benefits for this as I see it is:
>>
>> 1) No function overhead
>> 2) More readable (opinionated)
>> 3) Consistent with how we can select items from an array currently (using
>> index).
>>
>> If the array is not long enough (for example, index 4 doesn't exist), then
>> a NOTICE is thrown, and the values returned are as much as possible; this
>> would be the same as calling $array[1:] which will get the items in
>> position 1 through to the end.
>>
>> If the variable used contains a string, then this will get the values from
>> the string at those positions. The same way that $string[1] will get the
>> second character, $string[2:5] will get the third through to the sixth
>> character. This differs from array_slice which would throw a warning and
>> return null.
>>
>> If the variable isn't either a string or an array (or convertible to
>> either); then a warning is thrown and null is returned, consistent with
>> current use ($int[0] will return null)
>>
>> Arrays with associated keys cannot be selected by using the keys they
>> have,
>> but instead should be selected by the position those keys hold.
>>
>> For example, this is invalid:
>>
>> $array['string':'end']. This should throw a fatal error.
>>
>> The valid options are:
>>
>> $array[from:to] - This gets the values from position 'from' to 'to'
>> inclusive
>> $array[from:] - This gets the values from the position 'from' to the end.
>> $array[:to] - This gets the values from the start to the position 'to'.
>>
>> $array[:] will get all the items in the array ($same as doing $array)
>>
>> A side addition, that may be considered is adding [-1] to get the last
>> item
>> in the array. But that is not a main part of this RFC.
>>
>> Thanks
>>
>
>
> Variations of this proposal have been discussed many times.  I don't
> recall what the pushback was but it's worth your time to check the archives
> to see what the objections were and if you can address them, and/or if the
> new engine in PHP 7 addresses them.  (I suspect it has/will ameliorate a
> lot of implementation-level issues with old proposals.)
>
> Personally I'd be in favor of such a syntax but I don't recall the
> objections in the past beyond "meh, sugar".
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a1134676a5b26de0511aa94bb--