Re: [PHP-DEV] RFC - Array slice syntactic sugar
Would it make more sense then to have a RFC for array by positional index. No range or anything initially (that will be a separate RFC), but simply to get the value of an array by positional index? $array[*4] to get the item in position 4.
Re: [PHP-DEV] RFC - Array slice syntactic sugar
On 20 March 2015 at 10:38, Leigh lei...@gmail.com wrote: I've tried implementing python style slice on both strings and arrays in the past (I don't seem to have an existing branch with it in any more though it seems). The biggest problems I hit were regarding the syntax, the functionality itself worked. Colons caused problems with ternary operators in the lexer, and I had an issue with commas too, but I forget what it was. Of course these might have been resolvable, but I didn't put too much effort into it. That said, I'm a little older and wiser than I was then, I'd still be interested in looking at this. I'll try and come up with _something_ that works over the weekend.
Re: [PHP-DEV] RFC - Array slice syntactic sugar
On 20 March 2015 01:28:53 GMT, Alex Bowers bowersb...@gmail.com wrote: 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. What I mean by 'symbol' here, is a prefix to tell it what the context of its use is; in this case, it is the declaration that we are requiring the index not the key. As far as I'm aware, and can think of at the moment, PHP has nothing like a hinter symbol. The only purpose of this symbol is to tell the user that it is indexes not keys. The @ symbol in my examples is not a special marker that is meaningful on its own; the parser wouldn't even see it as a separate token. The syntax for key access is $array[$key], the syntax for positional access would be $array[@$position]; chosen to look similar, but one is not a special case of the other. The syntax needn't be just an extra character, we could invent something else, like $array[[$position]], or $array@($position), though I can't think of anything I like. Similarly, your suggested slice syntax is chosen to look similar to key access, and to the same feature in other languages, but since it doesn't exist yet, we can make up whatever parser rules we want. Maybe there should be a symbol to declare that, but i'm not sure. Will appreciate more comments on this. If we go the direction of using a symbol, what should be the outcome of the symbol missing? fatal error, or to try to slice based on the keys? The symbol isn't something that can be missing, it's just part of the syntax, so this is like saying what should we do if the closing ] is missing? The answer is, nothing, it's undefined syntax, so it's a parse error. You could implement slicing on keys, and if you did so, [x:y] would be the obvious syntax to use, but as you've said of negative positions, let's keep to one feature at a time. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
I've tried implementing python style slice on both strings and arrays in the past (I don't seem to have an existing branch with it in any more though it seems). The biggest problems I hit were regarding the syntax, the functionality itself worked. If you've got a link to your messaging thread, I'd love to read it. Thanks Colons caused problems with ternary operators in the lexer, and I had an issue with commas too, but I forget what it was. Of course these might have been resolvable, but I didn't put too much effort into it. Could this not be mitigated by adding a new token like T_COLON to be used to match this use case?
Re: [PHP-DEV] RFC - Array slice syntactic sugar
That said, I'm a little older and wiser than I was then, I'd still be interested in looking at this. I'll try and come up with _something_ that works over the weekend. I started on the code last night, but didn't get very far. I got it to match the T_COLON, but no logic or parsing has been done yet. I am still a bit shaky on how to implement this, so would definitely appreciate the help
Re: [PHP-DEV] RFC - Array slice syntactic sugar
The @ symbol in my examples is not a special marker that is meaningful on its own; the parser wouldn't even see it as a separate token. The syntax for key access is $array[$key], the syntax for positional access would be $array[@$position]; chosen to look similar, but one is not a special case of the other. Ah, I understand you now. Yes I agree that this would be useful then. It allows us the future possibility of a separate RFC looking into slicing on keys as mentioned at the bottom of your post. The syntax needn't be just an extra character, we could invent something else, like $array[[$position]], or $array@($position), though I can't think of anything I like. I think for simplicity, we should keep it as $array[], and have a symbol within it that shows that it is an internal index rather than the key. An Asterisk (*) is my preference at the moment, though caret also looks promising. Here are some examples of how various characters could look $array[*1:3], $array[*:], $array[*:1], $array[*1:] $array[@1:3], $array[@:], $array[@:1], $array[@1:] $array[^1:3], $array[^:], $array[^:1], $array[^1:] $array[1:3], $array[:], $array[:1], $array[1:] The symbol isn't something that can be missing, it's just part of the syntax, so this is like saying what should we do if the closing ] is missing? The answer is, nothing, it's undefined syntax, so it's a parse error. So a parse error currently, and a future RFC can define the terms of using this normally? If we go down the route of adding a symbol for by index rather than by key, then this RFC should also include the normal getting array by key style, without the colon range operator. For example: $array[*1] to get the item that is the second in the list, rather than at key 1.
Re: [PHP-DEV] RFC - Array slice syntactic sugar
Hi! This may be not so easy to implement - imagine passing $array[*1:4] by reference. This would be the same as doing $array[array_keys($old_array)[1]] = $new_array[0]; $array[array_keys($old_array)[2]] = $new_array[1]; $array[array_keys($old_array)[3]] = $new_array[2]; $array[array_keys($old_array)[4]] = $new_array[3]; I don't think you understood what I am saying. Lvalues in PHP can be used not only in assignment context, but also in passing-by-ref context, and in that case I have no idea how you pass $array[*1:4] by reference - what is actually passed? There is the array_splice method that can do the same thing, however this to me is less obvious as to what is happening: I don't see any reason why it would be less obvious, if you bother to look at man page of array_splice once. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
On 20 March 2015 at 23:03, Stanislav Malyshev smalys...@gmail.com wrote: $array[*1:4] by reference - what is actually passed? Implementation is not something I have looked into for this yet, so I am unsure how this would be possible; but by passing $array[*1:4], you'd be passing an extracted array which is a reference to the original array. Such that changing the sub array can change the parent array.
Re: [PHP-DEV] RFC - Array slice syntactic sugar
Hi! Implementation is not something I have looked into for this yet, so I am unsure how this would be possible; but by passing $array[*1:4], you'd be passing an extracted array which is a reference to the original array. Such that changing the sub array can change the parent array. Exactly. This means you can not make $array[*1:4] a real lvalue, which means you instead need to make it some kind of a hack on case-by-case basis, at which point it's no better than array_splice only implemented in more complicated way. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
Alex Bowers wrote on 20/03/2015 13:10: $array['x':'z'] = []; // Remove all elements with keys between 'x' and 'z', inclusive I believe i mentioned in the past about strings not being allowed for ranges, since there is no real way to check this (and this appears to be by key not by index) which should be a separate RFC thread, assuming this one gets accepted to be expanded upon. I'm carrying over my syntax from previous examples - [a:b] meaning a key-based slice (which implies accepting string keys, because there's no reason not to) vs [@a:b] meaning a positional slice. See my earlier mail on the 6 different types of access - I do realise you're not planning to implement them all, just playing with the implications of different decisions if we carry them through consistently in the future. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] RFC - Array slice syntactic sugar
Hi Rowan,
On Fri, 2015-03-20, at 13:17, Rowan Collins wrote:
I personally like the idea of string offsets having similar but slightly
different syntax from array offsets, to make clear which you're using. I
use {} instead of [] for that reason, but at the moment the syntaxes are
completely interchangeable as far as I can tell.
I'm in exactly the same situation; I'd thought for ages that the curly-brace
syntax was only valid for string offsets, so I use them in favour of square
brackets to avoid confusion.
I'd support reserving curly-braces for string offsets only (and vice-versa
for square brackets / arrays).
One awkward edge-case is where a class implements both __toString() and
ArrayAccess. It would be nice if you could distinguish which type of offset
you're accessing without casting.
Theoretical phpt test: http://pastebin.com/9b6YLC29
Vik
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
On Mar 20, 2015 12:33 PM, Alex Bowers bowersb...@gmail.com wrote: We also need to consider then the possibility of setting data by position. What should $array[@1:3] = [1,2,3] do? Should it overwrite the values there, and append any that don't exist, or should it be a parse error? I'd say overwrite/replace the range with the new value.
Re: [PHP-DEV] RFC - Array slice syntactic sugar
It's an alternative syntax
Learn something new every day.
I guess this RFC will need to support both then for consistency reasons; so
it will be down to the end user to determine how they want to separate them
if they choose to. But I don't think we should only match {} for strings
and [] for arrays, that seems broken to me.
Re: [PHP-DEV] RFC - Array slice syntactic sugar
We also need to consider then the possibility of setting data by position. What should $array[@1:3] = [1,2,3] do? Should it overwrite the values there, and append any that don't exist, or should it be a parse error?
Re: [PHP-DEV] RFC - Array slice syntactic sugar
On Mar 20, 2015 11:40 AM, Alex Bowers bowersb...@gmail.com wrote: I've tried implementing python style slice on both strings and arrays in the past (I don't seem to have an existing branch with it in any more though it seems). The biggest problems I hit were regarding the syntax, the functionality itself worked. If you've got a link to your messaging thread, I'd love to read it. Thanks Colons caused problems with ternary operators in the lexer, and I had an issue with commas too, but I forget what it was. Of course these might have been resolvable, but I didn't put too much effort into it. Could this not be mitigated by adding a new token like T_COLON to be used to match this use case? The only thing I could find is: http://chat.stackoverflow.com/transcript/11?m=15926856#15926856 If your branch is available on github let me know, more than happy work on it with you.
Re: [PHP-DEV] RFC - Array slice syntactic sugar
Alex Bowers wrote on 20/03/2015 13:09:
On 20 March 2015 at 13:04, Rowan Collins rowan.coll...@gmail.com
mailto:rowan.coll...@gmail.com wrote:
$version{4:} = '7!';
I'm sure this is a slight oversight on your end, but just to check.
The change of using {} instead of [] is not because its a string, and
is just a typo / example correct?
It's an alternative syntax, which I thought was only usable for string
indexing [1] but is apparently legal on arrays as well [2].
I personally like the idea of string offsets having similar but slightly
different syntax from array offsets, to make clear which you're using. I
use {} instead of [] for that reason, but at the moment the syntaxes are
completely interchangeable as far as I can tell.
[1]
http://php.net/manual/en/language.types.string.php#language.types.string.substr
[2]
http://php.net/manual/en/language.types.array.php#language.types.array.syntax.accessing
Regards,
--
Rowan Collins
[IMSoP]
Re: [PHP-DEV] RFC - Array slice syntactic sugar
On 20 March 2015 at 13:04, Rowan Collins rowan.coll...@gmail.com wrote:
$version{4:} = '7!';
I'm sure this is a slight oversight on your end, but just to check. The
change of using {} instead of [] is not because its a string, and is just a
typo / example correct?
Re: [PHP-DEV] RFC - Array slice syntactic sugar
Alex Bowers wrote on 20/03/2015 11:38: The @ symbol in my examples is not a special marker that is meaningful on its own; the parser wouldn't even see it as a separate token. The syntax for key access is $array[$key], the syntax for positional access would be $array[@$position]; chosen to look similar, but one is not a special case of the other. Ah, I understand you now. Yes I agree that this would be useful then. It allows us the future possibility of a separate RFC looking into slicing on keys as mentioned at the bottom of your post. The syntax needn't be just an extra character, we could invent something else, like $array[[$position]], or $array@($position), though I can't think of anything I like. I think for simplicity, we should keep it as $array[], and have a symbol within it that shows that it is an internal index rather than the key. An Asterisk (*) is my preference at the moment, though caret also looks promising. Here are some examples of how various characters could look $array[*1:3], $array[*:], $array[*:1], $array[*1:] $array[@1:3], $array[@:], $array[@:1], $array[@1:] $array[^1:3], $array[^:], $array[^:1], $array[^1:] $array[1:3], $array[:], $array[:1], $array[1:] The symbol isn't something that can be missing, it's just part of the syntax, so this is like saying what should we do if the closing ] is missing? The answer is, nothing, it's undefined syntax, so it's a parse error. So a parse error currently, and a future RFC can define the terms of using this normally? If we go down the route of adding a symbol for by index rather than by key, then this RFC should also include the normal getting array by key style, without the colon range operator. For example: $array[*1] to get the item that is the second in the list, rather than at key 1. Yep, I think we're on the same page now. There's basically three ways of selecting items - by key, by position from start, and by position from end - and two types of selection - a single element, or an array of zero or more elements. That gives us 6 possible combinations, which (using the @ notation for consistency with previous examples) would be: Select by key: Single element: $array[$x] - existing syntax Slice: $array[$a:$b] - equivalent to a filter asserting $key = $a $key = $b Select by position from start: Single element: $array[@$x] Slice: $array[@$a:$b],$array[@$a:], and $array[@:$b] Select by position from end - as above, but using negative indexes: Single element: $array[@-$x] - equivalent to $array[@length($array)-$x] Slice: $array[@-$a:-$b] - equivalent to $array[@length($array)-$a:length($array)-$b] Several of these are actually rather hard to do with current PHP features: - you can get the first element with reset() and the last with end(), but arbitrary position selection is harder - there is no version of array_filter for testing keys, and being able to write $dictionary['elephant':'snake'] would actually be pretty handy Actually, the only one that's easy to emulate (apart from the obvious single element by key) is the one you propose to add first - getting a positional slice of an array, which array_slice(..., true) already does. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] RFC - Array slice syntactic sugar
Alex Bowers wrote on 20/03/2015 12:32:
We also need to consider then the possibility of setting data by position.
What should $array[@1:3] = [1,2,3] do?
Should it overwrite the values there, and append any that don't exist,
or should it be a parse error?
Good catch. I guess it could delete the range and replace with the new
value, regardless of size - then you could remove elements from an array
with it, too:
$array[@1:3] = []; // Remove the second through fourth element
$array['x':'z'] = []; // Remove all elements with keys between 'x' and
'z', inclusive
Not sure how that compares to other languages with similar syntax.
It would be kind of cool if it applied to string subscripts as well:
$version = 'PHP 5.6.1';
$version{4:} = '7!';
echo $version; // 'PHP 7!'
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
$array['x':'z'] = []; // Remove all elements with keys between 'x' and
'z', inclusive
I believe i mentioned in the past about strings not being allowed for
ranges, since there is no real way to check this (and this appears to be by
key not by index) which should be a separate RFC thread, assuming this one
gets accepted to be expanded upon.
On 20 March 2015 at 13:04, Rowan Collins rowan.coll...@gmail.com wrote:
Alex Bowers wrote on 20/03/2015 12:32:
We also need to consider then the possibility of setting data by position.
What should $array[@1:3] = [1,2,3] do?
Should it overwrite the values there, and append any that don't exist, or
should it be a parse error?
Good catch. I guess it could delete the range and replace with the new
value, regardless of size - then you could remove elements from an array
with it, too:
$array[@1:3] = []; // Remove the second through fourth element
$array['x':'z'] = []; // Remove all elements with keys between 'x' and
'z', inclusive
Not sure how that compares to other languages with similar syntax.
It would be kind of cool if it applied to string subscripts as well:
$version = 'PHP 5.6.1';
$version{4:} = '7!';
echo $version; // 'PHP 7!'
Regards,
--
Rowan Collins
[IMSoP]
Re: [PHP-DEV] RFC - Array slice syntactic sugar
Okay, 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. In the list you provided, all of the ones for positional slicing will definitely be implemented. Question: What would be the best name for this feature? I do like *positional slicing,* but I'm sure there are better names out there. Since it isn't exclusively array based, and is entirely based on the index position (not key), positional slicing makes sense, and allows for the future to have key slicing implemented with their own separate documentation pages provided and clear naming for the differences between them. On 20 March 2015 at 13:21, Rowan Collins rowan.coll...@gmail.com wrote: Alex Bowers wrote on 20/03/2015 13:10: $array['x':'z'] = []; // Remove all elements with keys between 'x' and 'z', inclusive I believe i mentioned in the past about strings not being allowed for ranges, since there is no real way to check this (and this appears to be by key not by index) which should be a separate RFC thread, assuming this one gets accepted to be expanded upon. I'm carrying over my syntax from previous examples - [a:b] meaning a key-based slice (which implies accepting string keys, because there's no reason not to) vs [@a:b] meaning a positional slice. See my earlier mail on the 6 different types of access - I do realise you're not planning to implement them all, just playing with the implications of different decisions if we carry them through consistently in the future. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] RFC - Array slice syntactic sugar
On Mar 20, 2015 2:59 PM, Alex Bowers bowersb...@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.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] 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.
Re: [PHP-DEV] RFC - Array slice syntactic sugar
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]
Re: [PHP-DEV] RFC - Array slice syntactic sugar
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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
If your branch is available on github let me know, more than happy work on it with you. I'll publish it tonight (GMT), I'm at work at the moment. Thanks!
Re: [PHP-DEV] RFC - Array slice syntactic sugar
On Mar 20, 2015, at 16:52, Stanislav Malyshev smalys...@gmail.com wrote: Hi! 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. I'm not sure how such operation would be useful, and it definitely would not be intuitive, as $array[0] and $array[0:1] (assuming non-inclusive semantic, or [0:0] with inclusive semantics) would return completely different things. That would happen even if the array has only numeric keys! This is the main problem with this syntax - unlike most languages where it is used, PHP arrays are not vectors, they are ordered hashmaps. Sometimes this is very convenient, sometimes - like for this syntax - it is not. I think this is the major reason why such proposals failed in the past. My interest in this proposal is mostly because it can potentially provide a convenient way to get the first element in an array, which is a not-infrequent need of mine. I provided an array_key_first() implementation awhile ago that was first shot down because “too many array_* functions”, and then later ignored because I didn’t want to go through the RFC process just to add a few functions. (PR here: https://github.com/php/php-src/pull/347) If people are generally interested in having an array_key_(first|last|index) implementation, I can dust off that PR, update it for master, and if we really need an RFC, I’ll prepare one for PHP 7.1. -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
On Mar 20, 2015, at 3:04 PM, John Bafford jbaff...@zort.net wrote: If people are generally interested in having an array_key_(first|last|index) implementation, I can dust off that PR, update it for master, and if we really need an RFC, I’ll prepare one for PHP 7.1. -John I’d be very interested in this, though I don’t have voting karma. smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] RFC - Array slice syntactic sugar
The latest comments in this thread are talking about having a symbol before
the range to show that it is by positional index. Current propositions for
this are ^ and *.
I'm not sure how such operation would be useful
Anywhere on the front-end where a foreach() is used, and expects at most
say, 10 items. But the full dataset is fetched back (to show a summary
after the first 10 or whatever other reason).
The old code would have required a counter, the new code does not. This
would make it cleaner for the front-end developer to understand.
?php
$results = [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16];
// Old
$count = 0;
foreach($results as $result){
if($count++ 9) break;
echo $result . \n; // 1 2 3 4 5 6 7 8 9
}
// New
foreach($results[*:9] as $result) {
echo $result . \n; // 1 2 3 4 5 6 7 8 9
}
---
$string = abcdefghijklmnop;
// Old
echo substr($string, 0, 5); // abcde
// New
echo $string[*:4]; // abcdef
This is just a few basic examples, but should show that there is a use case
for it.
On 20 March 2015 at 20:52, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
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.
I'm not sure how such operation would be useful, and it definitely would
not be intuitive, as $array[0] and $array[0:1] (assuming non-inclusive
semantic, or [0:0] with inclusive semantics) would return completely
different things. That would happen even if the array has only numeric
keys! This is the main problem with this syntax - unlike most languages
where it is used, PHP arrays are not vectors, they are ordered hashmaps.
Sometimes this is very convenient, sometimes - like for this syntax - it
is not. I think this is the major reason why such proposals failed in
the past.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
On 20 March 2015 at 20:52, Stanislav Malyshev smalys...@gmail.com wrote: I'm not sure how such operation would be useful, and it definitely would not be intuitive, as $array[0] and $array[0:1] (assuming non-inclusive semantic, or [0:0] with inclusive semantics) would return completely different things. That would happen even if the array has only numeric keys! This is the main problem with this syntax - unlike most languages where it is used, PHP arrays are not vectors, they are ordered hashmaps. Sometimes this is very convenient, sometimes - like for this syntax - it is not. I think this is the major reason why such proposals failed in the past. It would give different results, for a reason. There is currently no way to get an array item by positional index, whilst preserving the keys. This RFC will allow that, with the inclusion of the symbol that will be required for this RFC (slicing by key can be a separate RFC; and is not covered by this RFC). So, if i want to get the items from position 1 through 5, I can use [*1:5] and I will get an array of the items in position 1,2,3,4 and 5; regardless of their keys, as an array.
Re: [PHP-DEV] RFC - Array slice syntactic sugar
Hi Alex,
On Fri, 2015-03-20, at 13:38, Alex Bowers wrote:
But I don't think we should only match {} for strings and [] for arrays,
that seems broken to me.
Certainly it breaks BC (and would presumably have to wait until PHP 8), but
if we were starting from scratch today, why would it make sense to have two
syntaxes that do exactly the same thing?
Vik
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
Certainly it breaks BC (and would presumably have to wait until PHP 8), but if we were starting from scratch today, why would it make sense to have two syntaxes that do exactly the same thing? Maybe you misunderstand me, I am against using two syntaxes for different things.
Re: [PHP-DEV] RFC - Array slice syntactic sugar
That's why I propose a new syntax such as $thing[@0], $thing[@-1] I have to agree that a new syntax will be required by this. On 20 March 2015 at 18:17, Rowan Collins rowan.coll...@gmail.com wrote: Leigh wrote on 20/03/2015 16:17: For $thing[-1] I think this only works for strings (and I have this implemented, should probably RFC it) https://github.com/lt/php-src/ tree/string_negative_offset $thing[-1:] is in scope for arrays though Why? Getting the last value of an array is just as useful as getting the last character of a string. It doesn't work *with that syntax*, because -1 is a valid key, just as $thing[0] can't mean first value of array because it already means value with key 0. That's why I propose a new syntax such as $thing[@0], $thing[@-1], etc. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] RFC - Array slice syntactic sugar
Is everybody happy with the RFC being called 'Slice Operator', or is there a better name for it? On 20 March 2015 at 18:17, Rowan Collins rowan.coll...@gmail.com wrote: Leigh wrote on 20/03/2015 16:17: For $thing[-1] I think this only works for strings (and I have this implemented, should probably RFC it) https://github.com/lt/php-src/ tree/string_negative_offset $thing[-1:] is in scope for arrays though Why? Getting the last value of an array is just as useful as getting the last character of a string. It doesn't work *with that syntax*, because -1 is a valid key, just as $thing[0] can't mean first value of array because it already means value with key 0. That's why I propose a new syntax such as $thing[@0], $thing[@-1], etc. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] RFC - Array slice syntactic sugar
Leigh wrote on 20/03/2015 16:17: For $thing[-1] I think this only works for strings (and I have this implemented, should probably RFC it) https://github.com/lt/php-src/tree/string_negative_offset $thing[-1:] is in scope for arrays though Why? Getting the last value of an array is just as useful as getting the last character of a string. It doesn't work *with that syntax*, because -1 is a valid key, just as $thing[0] can't mean first value of array because it already means value with key 0. That's why I propose a new syntax such as $thing[@0], $thing[@-1], etc. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
Yes, I'm very conscious of the substantial BC break, which is why I would target PHP 8 (or even 9, following a deprecation cycle). I would guess PHP 8, since you can deprecate things at 7.x Either way, if you make this a separate thread so we don't get off topic, and i'm sure you'll get many responses from people who want to have their say.
Re: [PHP-DEV] RFC - Array slice syntactic sugar
When you say restrict to one each. Do you mean one for strings and one for
arrays?
If so I'd have to disagree with this, since having the same operation
available to both is less likely to give mistakes. Can you give an example
of an actual benefit for this? Since this would cause a backwards
incompatible change. I can't imagine many places if any use the curly
brackets for arrays or strings, but since it exists there may be people
using it. Changing the behaviour of this to only work for one of the two
options seems unnecessary in the name of making code slightly more apparent
on initial reading. But variable names and so on should be used to help
distinguish from array or strings anyway.
On 20 Mar 2015 17:02, Vik Hudec vikhu...@yahoo.com wrote:
Hi Alex,
On Fri, 2015-03-20, at 14:52, Alex Bowers wrote:
But I don't think we should only match {} for strings and [] for arrays,
that seems broken to me.
Maybe you misunderstand me, I am against using two syntaxes for different
things.
Based on your reply; yes, I'm definitely misunderstanding! In summary, we
already have two different operations:
(1) Accessing an array's element using subscript notation, eg:
$foo = array('bar'); var_dump($foo[0]); // string(3) bar
(2) Accessing a string's character using subscript notation, eg:
$foo = 'bar'; var_dump($foo[0]); // string(1) b
And we already have two different syntaxes: $var[$offset] and
$var{$offset}.
So we have two syntaxes that each perform two operations. Are we in
agreement that this isn't a good thing?
Sorry that this is all a little off-topic, but I'm interested in people's
opinions because I'm considering a future RFC. My proposition would be to
restrict the two subscript syntaxes to one operation each. And if your
slice
sugar RFC aims to augment the functionality of either one or both of these
syntaxes, then that's relevant to me.
Vik
Re: [PHP-DEV] RFC - Array slice syntactic sugar
Alex Bowers wrote on 20/03/2015 16:00: 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. I have to agree, we are getting ahead of ourselves. A quick summary of what this RFC should cover: - Slicing an array or string based on the positional index. Things for future RFC consideration: - Slicing an array or string based on the key. - Index -1 for last item of list. Everybody agree that the only focus of this RFC should be the positional index slicing? I'd be tempted to introduce the ability to get a single element by position as well, just because that would be a really useful feature, and accessing array elements by their position is kind of pre-requisite for accessing a set of array elements by their positions anyway. It might also make the rationale for the eventual syntax more obvious to those who haven't been reading this conversation. :) Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] RFC - Array slice syntactic sugar
On 20 March 2015 at 16:17, Leigh lei...@gmail.com wrote: $thing[-1:] is in scope for arrays though How would this work for slicing? Since doing [@-1:] would mean get the last element to the end. And doing [@1:-1] is the exact same as doing [@1:] since -1 and blank both mean the end.
Re: [PHP-DEV] RFC - Array slice syntactic sugar
Alex, On Fri, 2015-03-20, at 17:19, Alex Bowers wrote: When you say restrict to one each. Do you mean one for strings and one for arrays? Yes, that's what I mean. I would propose square brackets for array offsets, and curly braces for strings. If so I'd have to disagree with this, since having the same operation available to both is less likely to give mistakes. Can you give an example of an actual benefit for this? Since this would cause a backwards incompatible change. I can't imagine many places if any use the curly brackets for arrays or strings, but since it exists there may be people using it. Changing the behaviour of this to only work for one of the two options seems unnecessary in the name of making code slightly more apparent on initial reading. But variable names and so on should be used to help distinguish from array or strings anyway. Yes, I'm very conscious of the substantial BC break, which is why I would target PHP 8 (or even 9, following a deprecation cycle). I guess you and I disagree on the benefits of syntax that is more self-documenting. The vast majority of PHP developers don't use variable names to indicate data types; the only common convention I've seen is for arrays' names to be pluralized (ie. $items, $rows etc.), but this doesn't really help. Often when less- experienced developers come across code that uses subscript syntax on a variable, they typically assume that the variable is an array (since string offsets are so much less common), and in doing so, introduce bugs. If the use of curly-braces was mandatory for string offsets, then code like this couldn't be mistaken for anything else. Vik -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
Hi Alex,
On Fri, 2015-03-20, at 14:52, Alex Bowers wrote:
But I don't think we should only match {} for strings and [] for arrays,
that seems broken to me.
Maybe you misunderstand me, I am against using two syntaxes for different
things.
Based on your reply; yes, I'm definitely misunderstanding! In summary, we
already have two different operations:
(1) Accessing an array's element using subscript notation, eg:
$foo = array('bar'); var_dump($foo[0]); // string(3) bar
(2) Accessing a string's character using subscript notation, eg:
$foo = 'bar'; var_dump($foo[0]); // string(1) b
And we already have two different syntaxes: $var[$offset] and $var{$offset}.
So we have two syntaxes that each perform two operations. Are we in
agreement that this isn't a good thing?
Sorry that this is all a little off-topic, but I'm interested in people's
opinions because I'm considering a future RFC. My proposition would be to
restrict the two subscript syntaxes to one operation each. And if your slice
sugar RFC aims to augment the functionality of either one or both of these
syntaxes, then that's relevant to me.
Vik
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
On Mar 20, 2015 4:00 PM, Alex Bowers bowersb...@gmail.com wrote: 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. I have to agree, we are getting ahead of ourselves. A quick summary of what this RFC should cover: - Slicing an array or string based on the positional index. Things for future RFC consideration: - Slicing an array or string based on the key. - Index -1 for last item of list. Everybody agree that the only focus of this RFC should be the positional index slicing? I think that's plenty for initial scope, since at this point proposals are targeting 7.1 there's plenty of time to get assoc indexing in if there is enough support for this in the first instance. If there is support for positional but not assoc, we don't want this proposal to fail on the fact they are bundled together. Not sure I understand your index -1 line (sorry, on phone in pub, really just skimming mails). If you mean negative indices for positions from the end of the array/string then +1 for this *with* the slice syntax. For $thing[-1] I think this only works for strings (and I have this implemented, should probably RFC it) https://github.com/lt/php-src/tree/string_negative_offset $thing[-1:] is in scope for arrays though
Re: [PHP-DEV] RFC - Array slice syntactic sugar
I'd be tempted to introduce the ability to get a single element by position as well Absolutely agree. Can we agree on a symbol do you think, or should the RFC continue for the symbol discussion?
Re: [PHP-DEV] RFC - Array slice syntactic sugar
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. I have to agree, we are getting ahead of ourselves. A quick summary of what this RFC should cover: - Slicing an array or string based on the positional index. Things for future RFC consideration: - Slicing an array or string based on the key. - Index -1 for last item of list. Everybody agree that the only focus of this RFC should be the positional index slicing?
Re: [PHP-DEV] RFC - Array slice syntactic sugar
I agree the scope is enough. Going with what Rowan added in about individual indexes (not slicing) by position to be added in with this, since the two go together. In my opinion, the $thing[-1] should be a separate RFC, since it has little to do with slicing, which is the primary focus of this RFC. On 20 March 2015 at 16:17, Leigh lei...@gmail.com wrote: On Mar 20, 2015 4:00 PM, Alex Bowers bowersb...@gmail.com wrote: 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. I have to agree, we are getting ahead of ourselves. A quick summary of what this RFC should cover: - Slicing an array or string based on the positional index. Things for future RFC consideration: - Slicing an array or string based on the key. - Index -1 for last item of list. Everybody agree that the only focus of this RFC should be the positional index slicing? I think that's plenty for initial scope, since at this point proposals are targeting 7.1 there's plenty of time to get assoc indexing in if there is enough support for this in the first instance. If there is support for positional but not assoc, we don't want this proposal to fail on the fact they are bundled together. Not sure I understand your index -1 line (sorry, on phone in pub, really just skimming mails). If you mean negative indices for positions from the end of the array/string then +1 for this *with* the slice syntax. For $thing[-1] I think this only works for strings (and I have this implemented, should probably RFC it) https://github.com/lt/php-src/tree/string_negative_offset $thing[-1:] is in scope for arrays though
Re: [PHP-DEV] RFC - Array slice syntactic sugar
On 20 March 2015 at 20:10, Sean Coates s...@seancoates.com wrote: That’s no different than `@` being invalid because it’s already in use. The syntax would be [*from:to], which would currently throw a parse error (since asterisk is required to be placed between two numbers), so this would be different. Alternatively, an underscore could be used This would then look like [_from:to] Also, another option would be to not use the square bracket syntax at all, and move towards angled brackets for positional indexing. This would then be $array1:2 to get items in positions 1 and 2.
Re: [PHP-DEV] RFC - Array slice syntactic sugar
There’s no existing unary form of * and ^, though, so I think they’d both
be available in this context (^ is my preference).
I think that is also my preference too.
On 20 March 2015 at 20:17, John Bafford jbaff...@zort.net wrote:
On Mar 20, 2015, at 16:10, Sean Coates s...@seancoates.com wrote:
I posted four suggestions earlier,
They were:
@
*
^
My favourites are the asterisk or caret.
That’s no different than `@` being invalid because it’s already in use.
$ php -a
Interactive shell
php define('a', 1);
php define('b', 2);
php echo @a . \n;
1
php echo (ab) . \n;
0
php echo (a*b) . \n;
2
php echo (a^b) . \n;
3
php
However: `☃` has a long history of being available to PHP.
S
There’s no existing unary form of * and ^, though, so I think they’d both
be available in this context (^ is my preference).
Overloading unary would probably also work in this context, but
personally, I think that is too overused.
-John
Re: [PHP-DEV] RFC - Array slice syntactic sugar
On Mar 20, 2015, at 16:27, Alex Bowers bowersb...@gmail.com wrote: On 20 March 2015 at 20:10, Sean Coates s...@seancoates.com wrote: That’s no different than `@` being invalid because it’s already in use. The syntax would be [*from:to], which would currently throw a parse error (since asterisk is required to be placed between two numbers), so this would be different. Alternatively, an underscore could be used This would then look like [_from:to] Also, another option would be to not use the square bracket syntax at all, and move towards angled brackets for positional indexing. This would then be $array1:2 to get items in positions 1 and 2. $array1:2 could be confusing to parse (if not confusing to read) because of ambiguity with the existing and operators. For example: $foo ? $bar1:2 3 is currently valid syntax, and means $foo ? ($bar 1) : (2 3) So there is probably some complex nesting of ?: and : that is entirely ambiguous. Not necessarily saying it can’t be done, but I think we should probably avoid syntax with a significant chance of causing mental parse errors. -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
On Mar 20, 2015, at 14:17, Rowan Collins rowan.coll...@gmail.com wrote: It doesn't work *with that syntax*, because -1 is a valid key, just as $thing[0] can't mean first value of array because it already means value with key 0. That's why I propose a new syntax such as $thing[@0], $thing[@-1], etc. I would just like to point out that the @ error suppression operator operates on expressions. Unfortunately, that means that also using @ as a slice operator makes the two ambiguous with each other in those contexts. The concept itself can still work, but it’d need a token other than @. -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
Hi! 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. I'm not sure how such operation would be useful, and it definitely would not be intuitive, as $array[0] and $array[0:1] (assuming non-inclusive semantic, or [0:0] with inclusive semantics) would return completely different things. That would happen even if the array has only numeric keys! This is the main problem with this syntax - unlike most languages where it is used, PHP arrays are not vectors, they are ordered hashmaps. Sometimes this is very convenient, sometimes - like for this syntax - it is not. I think this is the major reason why such proposals failed in the past. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
The concept itself can still work, but it’d need a token other than @. This is the symbol currently being used for examples, but thats all it is currently. Nothing is set in stone (and most likely will change), not just for this reason but for the reason that I mentioned earlier in the thread that the @ symbol has bad connotations, and avoiding these connotations would benefit the RFC. I posted four suggestions earlier, They were: @ * ^ My favourites are the asterisk or caret.
Re: [PHP-DEV] RFC - Array slice syntactic sugar
On Mar 20, 2015, at 16:10, Sean Coates s...@seancoates.com wrote:
I posted four suggestions earlier,
They were:
@
*
^
My favourites are the asterisk or caret.
That’s no different than `@` being invalid because it’s already in use.
$ php -a
Interactive shell
php define('a', 1);
php define('b', 2);
php echo @a . \n;
1
php echo (ab) . \n;
0
php echo (a*b) . \n;
2
php echo (a^b) . \n;
3
php
However: `☃` has a long history of being available to PHP.
S
There’s no existing unary form of * and ^, though, so I think they’d both be
available in this context (^ is my preference).
Overloading unary would probably also work in this context, but personally, I
think that is too overused.
-John
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
Alex Bowers wrote:
Anywhere on the front-end where a foreach() is used, and expects at most
say, 10 items. But the full dataset is fetched back (to show a summary
after the first 10 or whatever other reason).
The old code would have required a counter, the new code does not. This
would make it cleaner for the front-end developer to understand.
?php
$results = [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16];
// Old
$count = 0;
foreach($results as $result){
if($count++ 9) break;
echo $result . \n; // 1 2 3 4 5 6 7 8 9
}
// New
foreach($results[*:9] as $result) {
echo $result . \n; // 1 2 3 4 5 6 7 8 9
}
// alternative old
foreach(array_slice($results, 0, 9) as $result) {
echo $result . \n; // 1 2 3 4 5 6 7 8 9
}
Not so bad, in my opinion.
--
Christoph M. Becker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
// alternative old
foreach(array_slice($results, 0, 9) as $result) {
echo $result . \n; // 1 2 3 4 5 6 7 8 9
}
Not so bad, in my opinion.
To be the same, your example would have to be:
// alternative old
foreach(array_slice($results, 0, 9, true) as $result) {
echo $result . \n; // 1 2 3 4 5 6 7 8 9
}
since this will preserve the array keys.
This was a quick off the top of my head example; there is also the benefit
of overwriting multiple array items with a single line
$array[*1:4] = [1,2,3,4]; // Sets array items 1 through 4 to be the values
(and keys if provided), of the array assigned.
$array[*1:] = [1,2,3,4]; // Sets array items 1 to the end to be values (and
keys if provided), of the array assigned. This will also wipe out any
additional information to the end of the array. Keeping anything before the
first item, but extending until the end.
This would be similar to array_replace, however that works from keys, not
positions.
Re: [PHP-DEV] RFC - Array slice syntactic sugar
Hi! I provided an array_key_first() implementation awhile ago that was first shot down because “too many array_* functions”, and then later ignored because I didn’t want to go through the RFC process just to add a few functions. (PR here: https://github.com/php/php-src/pull/347) Adding array functions definitely requires and RFC process, arrays are primary data structure in PHP that stores practically everything, so having good API for them is essential. It's not that hard to make an RFC, and given that you propose a change which literally concerns millions of sites and developers, it's only to be expected that some formal description and discussion of the proposal is required. If people are generally interested in having an array_key_(first|last|index) implementation, I can dust off that PR, update it for master, and if we really need an RFC, I’ll prepare one for PHP 7.1. I imagine we do need an RFC for something like that. First element can be easily accessed with reset and each/current, but the last one is harder to access without modifying. So maybe it's be a good addition. There's a lot of time till 7.1 yet so you could definitely make a good RFC. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
Hi! It would give different results, for a reason. There is currently no way to get an array item by positional index, whilst preserving the keys. I imagine having such way may be useful. However, reusing array access syntax for that does not look like a good idea, since it would look like existing array syntax but work completely different. Why not use array_slice for it? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
Why not use array_slice for it? There certainly are ways to do most of what this RFC covers, however most of them don't lend themselves well to clean code in my opinion. Thats why this RFC is listed as being syntactic sugar. On 20 March 2015 at 21:30, Stanislav Malyshev smalys...@gmail.com wrote: Hi! It would give different results, for a reason. There is currently no way to get an array item by positional index, whilst preserving the keys. I imagine having such way may be useful. However, reusing array access syntax for that does not look like a good idea, since it would look like existing array syntax but work completely different. Why not use array_slice for it? -- Stas Malyshev smalys...@gmail.com
Re: [PHP-DEV] RFC - Array slice syntactic sugar
On Mar 20, 2015, at 17:27, Stanislav Malyshev smalys...@gmail.com wrote: Hi! I provided an array_key_first() implementation awhile ago that was first shot down because “too many array_* functions”, and then later ignored because I didn’t want to go through the RFC process just to add a few functions. (PR here: https://github.com/php/php-src/pull/347) Adding array functions definitely requires and RFC process, arrays are primary data structure in PHP that stores practically everything, so having good API for them is essential. It's not that hard to make an RFC, and given that you propose a change which literally concerns millions of sites and developers, it's only to be expected that some formal description and discussion of the proposal is required. Fair enough. Expect to see an RFC once the window for 7.1 opens. If people are generally interested in having an array_key_(first|last|index) implementation, I can dust off that PR, update it for master, and if we really need an RFC, I’ll prepare one for PHP 7.1. I imagine we do need an RFC for something like that. First element can be easily accessed with reset and each/current, but the last one is harder to access without modifying. So maybe it's be a good addition. There's a lot of time till 7.1 yet so you could definitely make a good RFC. reset + each/current modifies the array pointer, though, so it’s unfortunately not quite that easy. -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
Hi!
To be the same, your example would have to be:
// alternative old
foreach(array_slice($results, 0, 9, true) as $result) {
echo $result . \n; // 1 2 3 4 5 6 7 8 9
}
since this will preserve the array keys.
You're not using the keys in foreach, so why you need to preserve them?
$array[*1:4] = [1,2,3,4]; // Sets array items 1 through 4 to be the
values (and keys if provided), of the array assigned.
This may be not so easy to implement - imagine passing $array[*1:4] by
reference. You should be able to do so, since $array[*1:4] is an lvalue
for you, but what would you pass? What if $array changes in the
meantime? There's a big can of worms here. And you already have
array_splice which doesn't have these issues.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
Hi! There certainly are ways to do most of what this RFC covers, however most of them don't lend themselves well to clean code in my opinion. I must disagree with the notion that clean code can only include operators and not functions. There's nothing wrong with using functions. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
On 20 March 2015 at 22:12, Stanislav Malyshev smalys...@gmail.com wrote: You're not using the keys in foreach, so why you need to preserve them? This was merely an example of the features equal part in current code, not a real life use case. Using the new syntax will keep the keys preserved, therefore any example showing how to do the same *must* do the same, which preserving keys does. This may be not so easy to implement - imagine passing $array[*1:4] by reference. This would be the same as doing $array[array_keys($old_array)[1]] = $new_array[0]; $array[array_keys($old_array)[2]] = $new_array[1]; $array[array_keys($old_array)[3]] = $new_array[2]; $array[array_keys($old_array)[4]] = $new_array[3]; The new syntax helps clean that up, by doing: $array[*1:4] = [1,2,3,4]; There is nothing to pass by reference that is different, the array is still $array, it is just having the values replaced in bulk by index (not by key) This sort of code would be needed: ?php $old_array = [0 = 1, 1 = 2, 5 = 3, 7 = 4, 4 = 5, 2 = 6, 14 = 7, 55 = 8]; $new_array_values = ['foo', 'bar', 'baz']; // To replace the third, fourth and fifth element. $old_array[array_keys($old_array)[3]] = $new_array_values[0]; $old_array[array_keys($old_array)[4]] = $new_array_values[1]; $old_array[array_keys($old_array)[5]] = $new_array_values[2]; var_dump($old_array); Instead of, what is in my opinion, much cleaner: ?php $old_array = [0 = 1, 1 = 2, 5 = 3, 7 = 4, 4 = 5, 2 = 6, 14 = 7, 55 = 8]; $new_array_values = ['foo', 'bar', 'baz']; $old_array[*3:5] = $new_array_values; var_dump($old_array); There is the array_splice method that can do the same thing, however this to me is less obvious as to what is happening: ?php $old_array = [0 = 1, 1 = 2, 5 = 3, 7 = 4, 4 = 5, 2 = 6, 14 = 7, 55 = 8]; $new_array_values = ['foo', 'bar', 'baz']; // To replace the third, fourth and fifth element. array_splice($old_array, 3, 3, $new_array_values); var_dump($old_array);
Re: [PHP-DEV] RFC - Array slice syntactic sugar
On 19/03/2015 20:49, Alex Bowers wrote: 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. While I can see the reasoning for not looking into the actual keys (which might not have a logically sliceable order), I think the syntax needs to be more distinct, because this seems a bit confusing: $countdown = [ 5 = 'Five!', 4 = 'Four!', 3 = 'Three!', 2 = 'Two!', 1 = 'One!', 0 = 'Zero!' ] $countdown[0]; // 'Zero!' $countdown[0:0]; // ['Five!'] $countdown[0:][0] // 'Zero!' $countdown[:0][0] // null - slice contains no key 0 The problem is that the slice access looks like an extension of key access, but is actually a new concept of positional element access. With a slight tweak to syntax, such as adding an @, we could make positional access available for non-slices as well: reset($countdown); // Five! - a common way of getting the first element positionally $countdown[@0]; // 'Five!' $countdown[@1]; // 'Four!' $countdown[@0:0] // ['Five!'] $countdown[@0:1] // ['Five!', 'Four!'] $countdown[@0:][@0] // 'Five!' $countdown[@:0][@0] // 'Five!' 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. This would actually be a really important addition for me, but only if I can do it on a non-slice, as above: $countdown[-1]; // null - no such key end($countdown); // 'Zero!' - common way of getting last element $countdown[@-1]; // 'Zero!' - positional access counting from the end $countdown[@-2]; // 'One!' - fiddly to do in current PHP I just wrote out all those examples and realised that it may not be possible to reuse @ in this context. Finding new symbols to use for syntax is hard. :( Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
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). I agree with this statement now, I was misinterpreting how I thought it should work, but reading this; I think you're right. Also, your next point about the unique array indexes covers it anyway, so it doesn't really matter regardless. 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. You're correct, this was my mistake. 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. What I mean by 'symbol' here, is a prefix to tell it what the context of its use is; in this case, it is the declaration that we are requiring the index not the key. As far as I'm aware, and can think of at the moment, PHP has nothing like a hinter symbol. The only purpose of this symbol is to tell the user that it is indexes not keys. Maybe there should be a symbol to declare that, but i'm not sure. Will appreciate more comments on this. If we go the direction of using a symbol, what should be the outcome of the symbol missing? fatal error, or to try to slice based on the keys?
Re: [PHP-DEV] RFC - Array slice syntactic sugar
On 3/19/15 4:06 PM, Alex Bowers wrote: 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? Not everything makes it to an RFC. This list's archives are quite extensive. (People here are verbose): http://php.net/mailing-lists.php http://marc.info/?l=php-internals Also, no top-posting, please. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
On 19 March 2015 at 21:11, Larry Garfield la...@garfieldtech.com wrote: On 3/19/15 4:06 PM, Alex Bowers wrote: 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? Not everything makes it to an RFC. This list's archives are quite extensive. (People here are verbose): http://php.net/mailing-lists.php http://marc.info/?l=php-internals Also, no top-posting, please. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Apologies about the top post, that was gmail automatically hiding the main content so I just typed. Thanks for the links. I will look through them now to find some proposals which have failed before; and try to improve this one. Still would like feedback from anybody else reading this too. Thanks.
Re: [PHP-DEV] RFC - Array slice syntactic sugar
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
Re: [PHP-DEV] RFC - Array slice syntactic sugar
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 la...@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
