On 2024.04.07 17:20, Joshua Rüsweg wrote:
Hi
I have created an RFC to add the function array_find which returns the
first element for which a predicate callback returns true. This is a
function which I missed often. Furthermore this type of function is
implemented with other programming langua
Hi
On 5/25/24 01:19, Valentin Udaltsov wrote:
Have you considered renaming `$callback` parameter to `$predicate`? I
always considered "callback" to be a very generic word. Predicate, on the
contrary, implies accepting a value and returning a bool.
For an entirely new API I would agree. But fo
On Sun, Apr 7, 2024, at 10:20 AM, Joshua Rüsweg wrote:
> Hi
> I have created an RFC to add the function array_find which returns the
> first element for which a predicate callback returns true. This is a
> function which I missed often. Furthermore this type of function is
> implemented with other
Hi
On 5/6/24 20:44, Joshua Rüsweg wrote:
I don't think that any internal functions are realistically passed
there, but rather user-defined ones. I would therefore not make the
function any more complicated than it already is. If the function works
differently with internal functions than with us
Hi
On 02.05.24 15:27, Larry Garfield wrote:
It's not just that it errors confusingly. It's that the design as is would be
incompatible with any C-based function. A function that works with anything
*except* the standard library seems... problematic.
It's possible that, since these new funct
On Wed, May 1, 2024, at 9:26 PM, Joshua Rüsweg wrote:
> Hi
>
> On 01.05.24 12:26, Larry Garfield wrote:
>> This looks good to me, with one remaining exception, which isn't specific to
>> this function but should still be discussed: Always passing the value and
>> key to the callback is unsafe, fo
Hi
On 01.05.24 12:26, Larry Garfield wrote:
This looks good to me, with one remaining exception, which isn't specific to
this function but should still be discussed: Always passing the value and key
to the callback is unsafe, for two reasons.
1. If the callback is an internal function rather
Hi
On 19.04.24 23:29, Tim Düsterhus wrote:> Thinking about this: I believe
that it would make sense to bundle
array_any and array_every (or array_all, see below) within the same RFC
due to the similarity. It can be a separate vote for those two, but
having the option of getting all three would
On Tue, Apr 23, 2024, at 7:53 PM, Joshua Rüsweg wrote:
> Hi
>
> On 19.04.24 21:20, Joshua Rüsweg wrote:
>> I definitely see the point where there is an advantage to having two
>> separate methods and can definitely understand that it is easier for
>> developers to understand the control flow with
Hi
On 23.04.24 22:22, Levi Morrison wrote:
The RFC looks better to me. The
[Unaffected PHP Functionality][1] section looks like it needs
updating, though:
This RFC only adds two new functions and an enum to PHP and
only affects previously defined functions which are named as
the proposed funct
On Tue, Apr 23, 2024 at 1:53 PM Joshua Rüsweg wrote:
>
> Hi
>
> On 19.04.24 21:20, Joshua Rüsweg wrote:
> > I definitely see the point where there is an advantage to having two
> > separate methods and can definitely understand that it is easier for
> > developers to understand the control flow wi
Hi
On 19.04.24 21:20, Joshua Rüsweg wrote:
I definitely see the point where there is an advantage to having two
separate methods and can definitely understand that it is easier for
developers to understand the control flow without evaluating the
parameters.
I'm unsure if that's really necess
Hi
On 19.04.24 23:17, Tim Düsterhus wrote:
On 4/19/24 22:08, Larry Garfield wrote:
There's another issue, though: Will the callback always be given both
$value and $key?
The current implementation always passes both, which, as I just learned,
is inconsistent with `array_filter` which has th
Hi
On 4/9/24 21:49, Tim Düsterhus wrote:
However I'm not sure if adding new array functions piecemeal is the
right choice at this point. array_any and array_every are conceptually
very similar to array_find and are missing as well. In fact
array_any($cb, $array) = array_find($cb, $array, true) !
Hi
On 4/19/24 22:08, Larry Garfield wrote:
There's another issue, though: Will the callback always be given both $value and $key?
The current implementation always passes both, which, as I just learned,
is inconsistent with `array_filter` which has the `$mode` parameter to
control what to pa
On Fri, Apr 19, 2024, at 7:34 PM, Joshua Rüsweg wrote:
> Hi
>
> On 10.04.24 00:12, Larry Garfield wrote:
>> Another alternative is to always return the key, because you can trivially
>> get the value from the key, but not vice versa. Of course, the resulting
>> syntax for that is frequently fugl
Hi
On 10.04.24 00:12, Larry Garfield wrote:
Another alternative is to always return the key, because you can trivially get
the value from the key, but not vice versa. Of course, the resulting syntax
for that is frequently fugly.
$val = $array[array_find($db, $array)] ?? some-default;
In 9
On 11.04.24 03:03, Levi Morrison wrote:
IMO, it's better to separate it into two functions because its type is
stable without control flow. For instance:
// Returns K if $b is true, V otherwise.
function array_find(
array $array,
callable(V, K): bool $callback,
> On 07.04.24 16:35, Larry Garfield wrote:
> > 1. Should this work on arrays or iterables? This is a long standing
> > limitation of PHP. The array operations don't work on iterables, even
> > though we've had iterables for 20 years.)
>
> In the longer term, it definitely makes sense to create
On Sun, Apr 7, 2024 at 8:38 AM Larry Garfield wrote:
>
> On Sun, Apr 7, 2024, at 10:20 AM, Joshua Rüsweg wrote:
> > Hi
> > I have created an RFC to add the function array_find which returns the
> > first element for which a predicate callback returns true. This is a
> > function which I missed oft
Hi
On 4/10/24 00:12, Larry Garfield wrote:
I feel the same. Adding an enum for each binary parameter that is
semantically true and false feels quite unwieldy with how class / enums
/ interfaces are currently organized in the namespace hierarchy.
Point of order: This parameter is *not* semantic
On Tue, Apr 9, 2024, at 7:49 PM, Tim Düsterhus wrote:
> However I'm not sure if adding new array functions piecemeal is the
> right choice at this point. array_any and array_every are conceptually
> very similar to array_find and are missing as well. In fact
> array_any($cb, $array) = array_fin
Hi
On 4/7/24 21:10, Joshua Rüsweg wrote:
On 07.04.24 16:35, Larry Garfield wrote:
1. Should this work on arrays or iterables? This is a long standing limitation
of PHP. The array operations don't work on iterables, even though we've had
iterables for 20 years.)
In the longer term, it defi
Hi
On 07.04.24 16:35, Larry Garfield wrote:
1. Should this work on arrays or iterables? This is a long standing limitation
of PHP. The array operations don't work on iterables, even though we've had
iterables for 20 years.)
In the longer term, it definitely makes sense to create a separate
On Sun, Apr 7, 2024, at 10:20 AM, Joshua Rüsweg wrote:
> Hi
> I have created an RFC to add the function array_find which returns the
> first element for which a predicate callback returns true. This is a
> function which I missed often. Furthermore this type of function is
> implemented with ot
Hi
I have created an RFC to add the function array_find which returns the
first element for which a predicate callback returns true. This is a
function which I missed often. Furthermore this type of function is
implemented with other programming languages like C++, JavaScript and
Rust, too.
Y
26 matches
Mail list logo
