Re: [PHP-DEV] Proposal: addition of array_find() and array_find_key() functions
sounds like array_find could be implemented by just adding a new flag for array_filter's $mode: ARRAY_FILTER_STOP_ON_FIRST_MATCH or some such? On Fri, 2 Jun 2023 at 02:15, Casper Langemeijer wrote: > > On Thu, Jun 1, 2023, at 18:02, Janusz Szczypka wrote: > > array_find(): This function would allow developers to find the first > > element in > > an array that satisfies a specific condition. The condition would be > > defined by a callback function. > > This would actually be an alternative to a simple foreach() with an if() and > a break. As your example implementation makes clear. > > array_find() and array_find_key() would still do the same internally, but add > a function call adding the overhead of pushing parameters to stack, switching > the scope, passing return value back switch scope and pop from the callstack > again. If parameters or return value are typed this adds even more overhead. > > I don't think there is any optimisation possible when this is done in C. > > To the proposer it probably feels that this is an array function currently > missing, but instead it's probably better not to have array_find() because > people might actually use it for larger datasets. > > Although I acknowledge that it will reduce the number of lines of PHP code it > doesn't actually reduce the mental capacity to read and maintain code. I find > the simple elemental building blocks of loops, conditionals and expressions > easier and more expressive. In my experience this is especially so for less > experienced developers. > > Then there is a problem of naming. array_search() and array_find(). To a new > developer, how would they know which is which? > > Also there is the missing array_find_value_and_key() method. Because why > should we be limited to either matching the key OR the value? > > Greetings, Casper > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: addition of array_find() and array_find_key() functions
On Thu, Jun 1, 2023, at 18:02, Janusz Szczypka wrote: > array_find(): This function would allow developers to find the first element > in > an array that satisfies a specific condition. The condition would be defined > by a callback function. This would actually be an alternative to a simple foreach() with an if() and a break. As your example implementation makes clear. array_find() and array_find_key() would still do the same internally, but add a function call adding the overhead of pushing parameters to stack, switching the scope, passing return value back switch scope and pop from the callstack again. If parameters or return value are typed this adds even more overhead. I don't think there is any optimisation possible when this is done in C. To the proposer it probably feels that this is an array function currently missing, but instead it's probably better not to have array_find() because people might actually use it for larger datasets. Although I acknowledge that it will reduce the number of lines of PHP code it doesn't actually reduce the mental capacity to read and maintain code. I find the simple elemental building blocks of loops, conditionals and expressions easier and more expressive. In my experience this is especially so for less experienced developers. Then there is a problem of naming. array_search() and array_find(). To a new developer, how would they know which is which? Also there is the missing array_find_value_and_key() method. Because why should we be limited to either matching the key OR the value? Greetings, Casper
Re: [PHP-DEV] [RFC] [Discussion] Add new function `array_group`
On Thu, Jun 1, 2023, at 11:56, Boro Sitnikovski wrote: > Thank you for the suggestion, I like this approach and it's definitely much > "safer" than going with an RFC for core directly. > > What are your thoughts on creating a PECL extension called `array_utils` > (selling point would be high performance array utils or something), which in > the future might contain more than `array_group*`, and the approach would be > to cherry-pick those functions that have frequent usage in codebases into > core? Or would it be better to stick to a particular/more concrete extension? I don't know. Also, I have no way of knowing if this would work. Although I mail using my php.net email address, and that could convey some authority, I really do not have that. My contribution to PHP is limited to maintaining the PECL ssh2 extension. Most of what I do is merging stuff other people write, keep an eye on bugs, Toss out GitHub issues when they are not relevant or lack real information, and update documentation. Sometimes chances to extension code are required by changes in the PHP interface. Mostly it's all minor stuff, and not much work. If you end up at the stage where you start writing C code, let me know if you think I can be of value to you. I really value other people's contributions in open source projects and enjoy contributing to create a better working development community. I think there can be value in every step that can be taken in developing software. But you should be very realistic in your expectations of code ending up in PHP core. If you can enjoy the process, see the value in the steps in between, if you are prepared to learn stuff that everyone around here already seems to know but somehow is not written down anywhere except in the code of php or other extensions, it is really fun and will bring you insights that are invaluable in working with PHP. Greetings, Casper
[PHP-DEV] RFC Karma
Hi Internals, As per my earlier post discussing the concept of an RFC to add public properties to interfaces, I would like to request karma to create this RFC. Thanks, Nick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: addition of array_find() and array_find_key() functions
Hey, Native implementation of the function array_find would decrease number of lines needed to perform basic loops over the arrays from 4-6 lines to just 1. And I recollect a few times when the argument of reducing lines of code needed to type was a valid reason of implementing the change. Moreover, only this function would allow to achieve the same result as proposed functions any()/all() by Tyson Andre 3 years ago. I still cannot understand the context why the rejection reasons as "Too small in scope/Object to the choice of namespace/Prefer the global namespace" prevented PHP to have something which is a basically standard in other languages. https://wiki.php.net/rfc/any_all_on_iterable Kind regards, Jorg
Re: [PHP-DEV] Proposal: addition of array_find() and array_find_key() functions
Hi On 6/1/23 18:29, Larry Garfield wrote: As with the array_group thread: What is the argument to put these functions in hard to update C, rather than PHP that is easy to download with Composer? "could be a nice addition" is not a compelling argument. Is it substantially faster? It is truly universally used? Does it correct some security concern? I am not sure if "hard to update" is a argument that applies here: There is only one reasonable implementation of array_find and thus once the function is written it is exceedingly unlikely to need any updates. When was the last time `array_filter`, which is likely the most similar existing function, needed an update? From the list you've given, "universally used" appears to be the most fitting description. A programming language needs a reasonable standard library and `array_find()` [1] is something that should pop up reasonably often in "functional array processing". It's available in various languages [2]. My only concern is that this either is another function that either instead of working on any iterable, works on arrays and arrays only - or a function that is inconsistent with the rest of the array_* functions. See also the discussion here: https://externals.io/message/118896#118896 Best regards Tim Düsterhus [1] As well as array_any() and array_all(). [2] JS: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/find Rust: https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.find Haskell: https://hackage.haskell.org/package/base-4.18.0.0/docs/Data-List.html#v:find C++: https://en.cppreference.com/w/cpp/algorithm/find -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: addition of array_find() and array_find_key() functions
On Thu, Jun 1, 2023, at 4:02 PM, Janusz Szczypka wrote:
> Dear PHP Internals,
>
> I would like to propose new functions to search in arrays: array_find() and
> array_find_key().
>
> array_find(): This function would allow developers to find the first
> element in
> an array that satisfies a specific condition. The condition would be
> defined by
> a callback function. The functionality would be similar to the existing
> array_filter() function but would instead return the first element that
> matches
> the callback condition, rather than all matching elements.
> This function can be used in a way simliar to in_array with added
> functionality
> of custom check.
>
> array_find_key(): This function would return the key of the first
> element in an
> array that matches a given condition, defined by a callback function. This
> function can be used in a way simliar to array_search with added
> functionality
> of custom check.
>
> Both functions stop processing after first match is found, so any side
> effects
> of the callbacks should be avoided.
>
> Here are the proposed function definitions:
>
> /**
> * @param callable(mixed):bool $callback
> */
> function array_find(callable $callback, array $array)
> {
> foreach ($array as $row) {
> if (call_user_func($callback, $row) === true) {
> return $row;
> }
> }
> return null;
> }
>
> /**
> * @param callable(mixed):bool $callback
> * @return null|int|string
> */
> function array_find_key(callable $callback, array $array)
> {
> foreach($array as $key => $row) {
> if (call_user_func($callback, $row) === true) {
> return $key;
> }
> }
> return null;
> }
>
> Both functions are easy to implement in PHP (and probably as easy to
> implement
> in C), but IMHO could be nice addition to set of array related functions
> in PHP.
>
> If the response to this e-mail will be positive, I will prepare RFC.
> We should also discuss order of arguments as the functions are similar
> to both
> array_search/in_array with condition-array and array_filter with
> array-condition, but as you can see above I am leaning towards
> condition-array.
>
> Looking forward to hearing your thoughts.
>
> Best regards,
> Janusz
As with the array_group thread:
What is the argument to put these functions in hard to update C, rather than
PHP that is easy to download with Composer? "could be a nice addition" is not
a compelling argument. Is it substantially faster? It is truly universally
used? Does it correct some security concern?
Those are the questions that stdlib additions need to answer.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC] [VOTE] Define proper semantics for range() function
Hello internals, The vote for the Define proper semantics for range() function RFC is now open and will last for two weeks until the 15th of June 2023: https://wiki.php.net/rfc/proper-range-semantics Best regards, George P. Banyard
[PHP-DEV] Proposal: addition of array_find() and array_find_key() functions
Dear PHP Internals,
I would like to propose new functions to search in arrays: array_find() and
array_find_key().
array_find(): This function would allow developers to find the first
element in
an array that satisfies a specific condition. The condition would be
defined by
a callback function. The functionality would be similar to the existing
array_filter() function but would instead return the first element that
matches
the callback condition, rather than all matching elements.
This function can be used in a way simliar to in_array with added
functionality
of custom check.
array_find_key(): This function would return the key of the first
element in an
array that matches a given condition, defined by a callback function. This
function can be used in a way simliar to array_search with added
functionality
of custom check.
Both functions stop processing after first match is found, so any side
effects
of the callbacks should be avoided.
Here are the proposed function definitions:
/**
* @param callable(mixed):bool $callback
*/
function array_find(callable $callback, array $array)
{
foreach ($array as $row) {
if (call_user_func($callback, $row) === true) {
return $row;
}
}
return null;
}
/**
* @param callable(mixed):bool $callback
* @return null|int|string
*/
function array_find_key(callable $callback, array $array)
{
foreach($array as $key => $row) {
if (call_user_func($callback, $row) === true) {
return $key;
}
}
return null;
}
Both functions are easy to implement in PHP (and probably as easy to
implement
in C), but IMHO could be nice addition to set of array related functions
in PHP.
If the response to this e-mail will be positive, I will prepare RFC.
We should also discuss order of arguments as the functions are similar
to both
array_search/in_array with condition-array and array_filter with
array-condition, but as you can see above I am leaning towards
condition-array.
Looking forward to hearing your thoughts.
Best regards,
Janusz
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Add new function `array_group`
> On 1.6.2023, at 09:18, Casper Langemeijer wrote: > > On Thu, Jun 1, 2023, at 01:19, Boro Sitnikovski wrote: >> Thank you for the information and encouragement! I was a bit scared of this >> one being rejected too, but still decided to give it a shot :) > > As an alternative approach this is what I would do in your situation: > > I would start with a PHP implementation, gather some opinions on what this > method would do, how it should work. Finalising the functional specification > to a point where you find broad acceptance. This would also allow others to > help performance optimise your implementation. > > Then start a PECL extension implementing the exact same thing in C code. This > could start as a niche for people that really need the extra performance the > extension would bring, possibly grow out to something that is defacto > standaard. > > PECL extensions are documented in the PHP manual, so the manual could have > your array_group() function described, possibly with a reference to the > original PHP implementation/ polyfill. > > This approach minimises dependence on internals giving a green light and > maximises the possibility to work with others as a team on this. It would > give you a chance to prove that the solution you provide is actually wanted > by users. If that really is the case, if it came to vote to merging the > extension into PHP itself the vote could be different than the vote on the > former RFC. > > Greetings, Casper Thank you for the suggestion, I like this approach and it's definitely much "safer" than going with an RFC for core directly. What are your thoughts on creating a PECL extension called `array_utils` (selling point would be high performance array utils or something), which in the future might contain more than `array_group*`, and the approach would be to cherry-pick those functions that have frequent usage in codebases into core? Or would it be better to stick to a particular/more concrete extension? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Add new function `array_group`
On Thu, Jun 1, 2023, at 01:19, Boro Sitnikovski wrote: > Thank you for the information and encouragement! I was a bit scared of this > one being rejected too, but still decided to give it a shot :) As an alternative approach this is what I would do in your situation: I would start with a PHP implementation, gather some opinions on what this method would do, how it should work. Finalising the functional specification to a point where you find broad acceptance. This would also allow others to help performance optimise your implementation. Then start a PECL extension implementing the exact same thing in C code. This could start as a niche for people that really need the extra performance the extension would bring, possibly grow out to something that is defacto standaard. PECL extensions are documented in the PHP manual, so the manual could have your array_group() function described, possibly with a reference to the original PHP implementation/ polyfill. This approach minimises dependence on internals giving a green light and maximises the possibility to work with others as a team on this. It would give you a chance to prove that the solution you provide is actually wanted by users. If that really is the case, if it came to vote to merging the extension into PHP itself the vote could be different than the vote on the former RFC. Greetings, Casper
