Re: [PHP-DEV] Two new functions array_first() and array_last()

[Deleu]

On Tue, Oct 17, 2023 at 3:43 PM Brandon Jackson 
wrote:

> > There is also a technique to make the return value `[$key => $value]`
> instead of just a value, but this loses simplicity.
>
> Hmm, since the naming array_first and array_last doesn't clarify that
> it's returning a key or a value. What if it returned both as ?[key,
> value].
>
> That opens quite a few use possibilities:
> $first = array_first($array);
> $value = $first[1] ?? throw new Exception();
>
> [,$value] = array_first($array) ?? [null, null];
> [,$value] = array_first($array) ?? throw new Exception();
>

This function signature can be accomplished by userland once we have
`array_key_first()` and `array_first()`. It's much better to keep
`array_first()` as simple as possible and let everyone build their own
approach to go about it since we have so many approaches.




-- 
Marco Deleu

Re: [PHP-DEV] Two new functions array_first() and array_last()

[Saki Takamachi]

I thought of it after sending the email, so I'll post it again. By combining my 
two ideas, I think I can come up with a smarter proposal.

```
array_first(array $array, int|string &$key = null)
```

If you want to accurately determine whether an array is empty or not, you can 
satisfy your request by checking if the key is null. Users who do not think 
accurate determination is necessary can omit the second argument.

And if you also want a key, it can fulfill that request as well.

Regards.

Saki
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Two new functions array_first() and array_last()

[Saki Takamachi]

Since reset() and end() return false when the array is empty, in a sense, there 
is an idea that there is no need to take such strict care of the return value.

If you were to take proper care, you would probably specify a default value or 
throw an exception, as has already been suggested. However, specifying a 
default value is not very smart in my opinion.

The fact that what value is considered to be "unable to obtain" changes 
depending on the situation causes some complexity. And when dealing with an 
array whose values ​​are completely unknown, it becomes necessary to "hope" 
that the values ​​do not conflict with the default values.

Can the following signature meet your requirements? Or will it become too 
complicated?

```
// arrar_first(array $arr, bool &$has_value)
$value = array_first($arr, $has_value);
if ($has_value) {
// array has items
// $value is mixed
} else {
// array is empty
// $value === null
}
```

Regards.

Saki
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Change default method of disabling JIT for PHP 8.4

[Jorg Sowa]

Hello Daniil,
I like this proposition. I never understood why the JIT is disabled by the
ini setting `buffer_size` rather than other simple 'switch' like setting.

Kind regards,
Jorg

Re: [PHP-DEV] proc_open() resource to opaque object migration

[Máté Kocsis]

Hi Tim,


> I agree here. While I'm totally in favor of using namespaces in core, it
> should be done somewhat consistently. If the proc_* functions are in the
> global namespace, then so should the resource object.
>

While I don't necessarily want to add a dedicated namespace for Process (or
whatever name we settle on), I don't agree with the reasoning: the resource
to
opaque object migration project is just a first step, afterwards, a new
object
oriented API could be added (as you already noted), and later on,
the procedural
one should be deprecated. That's why I think this kind of consistency is
not important
in this case. Please note that many such opaque objects have been added to
namespaces recently (e.g. FTP\Connection, IMAP\Connection,
LDAP\Connection etc.). so we already have some precedent.

I agree with the rest of your answer though. My favourite name is Process
and
I am fine with ProcessHandle as well. The latter name was proposed by
Nicolas in a private conversation.

In my opinion, a straw poll should decide the naming question. I honestly
don't
think that the change needs any more discussion/an RFC, as it doesn't cause
any larger BC break than some of the other resource migrations we performed
since PHP 8.0 -- and there were a lot of them: resources of around 20
extensions
got converted to proper objects among curl, openssl, and pgsql just to
mention some.
I'd argue that at least ext/curl is more widespread than proc_* functions
are.

Regards,
Máté

Re: [PHP-DEV] RFC Karma request

[Ilija Tovilo]

Hi Daniil

On Tue, Oct 17, 2023 at 8:25 PM Daniil Gentili  wrote:
> I'd like to create RFCs at least for final anonymous classes
> (https://externals.io/message/121356) and a small tweak to JIT defaults
> (https://externals.io/message/121359).
>
> Please give me RFC Karma :)
>
> Username: danog

RFC karma was granted, good luck with your RFC!

Ilija

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Previous discussions about generics syntax only?

[Rowan Tommins]

On 16/10/2023 15:08, Olle Härstedt wrote:

Hello internals,

Was there a previous discussion about the pros/cons of adding only the
syntax needed for generics, but not the functionality? So static
analyzers could use it, instead of docblocks. I looked at externals.io
but couldn't find anything specific.



Hi Olle,

Since I haven't seen it expressed quite this way in the previous 
discussion, I'd like to highlight what I think is a major downside to 
this approach, at least as commonly proposed:


Using the same syntax for type information that is guaranteed to be true 
(existing run-time checks) and type information that is "advisory only" 
(new checks for optional static analysis) means users can no longer have 
confidence in that type information.


This is one of the interesting things about the compromise over scalar 
types - if you see a declaration "function foo(int $bar) { ... }", you 
*know* that $bar will be an int at the start of every invocation of that 
function, regardless of which mode the calling code uses. I think adding 
exceptions to that certainty would be a bad direction for the language.


On the other hand, I can see a "third way": if the problem with current 
static analysis conventions is that they have to be parsed out of a 
string-based docblock, we can provide *dedicated* syntax, without 
unifying it with the standard type syntax. For instance, some of the 
earlier discussions around introducing attributes suggested reflection 
expose the AST of the attributes arguments, rather than the resolved 
expressions, allowing them to act a bit like Rust's "hygienic macros". 
If that was added as an optional mode, you might be able to do something 
like this:


#[RawAttribute]
class GenericType {
    public function __construct(AST\Node $typeInfo) { ... }
}

function foo(#[GenericType(int|float)] array $foo) {
    // array is the type guaranteed by the language
    // static analysis libraries can get the GenericType attribute from 
reflection and receive an AST representing the type constraint int|float

}

The actual attributes could either be built-in, making them official 
parts of the language, or managed in a library that static analysers 
co-operate on, making them standardised but more agile.



Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Two new functions array_first() and array_last()

[Brandon Jackson]

> There is also a technique to make the return value `[$key => $value]` instead 
> of just a value, but this loses simplicity.

Hmm, since the naming array_first and array_last doesn't clarify that
it's returning a key or a value. What if it returned both as ?[key,
value].

That opens quite a few use possibilities:
$first = array_first($array);
$value = $first[1] ?? throw new Exception();

[,$value] = array_first($array) ?? [null, null];
[,$value] = array_first($array) ?? throw new Exception();

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] RFC Karma request

[Daniil Gentili]

Hi, internals.

I'd like to create RFCs at least for final anonymous classes 
(https://externals.io/message/121356) and a small tweak to JIT defaults 
(https://externals.io/message/121359).


Please give me RFC Karma :)

Username: danog

Kind regards,
Daniil Gentili.

--

GitHub: https://github.com/danog

--

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Change default method of disabling JIT for PHP 8.4

[Daniil Gentili]

Hello,

I would like to submit an RFC and PR to change a few INI defaults for 
opcache, changing how JIT is disabled by default.


Currently, JIT is disabled by default using the 
|opcache.jit_buffer_size=0| default, instead of |opcache.jit=0|.


I.e. here are the defaults for these two configuration entries:

- opcache.jit=tracing
- opcache.jit_buffer_size=0

This effectively disables JIT not because `jit=0`, but rather because 
the buffer size is set to 0.


I would like to change these defaults to:

- opcache.jit=off
- opcache.jit_buffer_size=64m (taken from 
https://github.com/php/php-src/pull/12425/files, any smaller multiple of 
2 causes the buffer to fill up when running moderately sized projects 
like Psalm or PHPStan).


What do you think?


Kind regards,

Daniil Gentili.

[PHP-DEV] Deprecate posix_times

[Daniil Gentili]

Hi everyone,

I would like to submit an RFC (and related PR) to deprecate posix_times 
for PHP 8.4, removing it for PHP 9.


There are multiple reasons to deprecate this function:

1)

The values which times(2) returns are expressed as the number of clock 
ticks elapsed since the process was started: the frequency of the 
aforementioned clock varies from platform to platform, and PHP does not 
expose the sysconf(2) function, which is what should be used to fetch 
the clock frequency, invoking `sysconf(_SC_CLK_TCK)`.


Thus, users have to deal with time values which **cannot be portably 
converted to microseconds**: this has actually bitten us @ work, where I 
recently found an ancient piece of code which incorrectly hardcoded the 
(undocumented) clock frequency of 100hz used on (most) Linux platforms: 
running the code on a Linux platform like ia64 [1], or any other POSIX 
OS which uses a different clock frequency would have silently reported 
an incorrect value, with no way to obtain the correct clock frequency 
from PHP.


2)

Equivalent functionality is already provided by getrusage(), with a 
*much higher resolution*:


*a.php:*

    'utime_times' => $stat['utime'] * 10_000, // Assuming 100 hertz 
clock on x86 linux
    'stime_times' => $stat['stime'] * 10_000, // Assuming 100 hertz 
clock on x86 linux


    'utime_rusage' => $r['ru_utime.tv_usec'] + ($r['ru_utime.tv_sec'] * 
1000_000),
    'stime_rusage' => $r['ru_stime.tv_usec'] + ($r['ru_stime.tv_sec'] * 
1000_000),

];

var_dump($res);


*Result:*

array(4) {
  ["utime_times"]=>
  int(16)
  ["stime_times"]=>
  int(0)
  ["utime_rusage"]=>
  int(163672)
  ["stime_rusage"]=>
  int(4994)
}


As you can see, with a system time of ~5 milliseconds, posix_times() 
even returns 0, since the minimum duration that can be represented with 
a 100 hertz clock (the default on most Linux platforms) is 10 milliseconds.



Waiting for feedback, kind regards,

Daniil Gentili.


[1]: 
https://github.com/bminor/glibc/blob/69239bd7a216007692470aa9d5f3658024638742/sysdeps/unix/sysv/linux/ia64/getclktck.c

Re: [PHP-DEV] Final anonymous classes

[Saki Takamachi]

Hi, Daniil

> Personally, I would have instead preferred the much cleaner approach of 
> making *all* anonymous classes final by default, (preferrably) without 
> offering the option to make them non-final.
> 
> However, I understand that this might be a little bit too restrictive for 
> something that may have some valid usecases, even if extending anonymous 
> classes currently requires some hack-ish workarounds with class_alias.
> 
> 
> All in all, as per the title, I'd just like to add support for final 
> anonymous classes (new final class {}), without changing any existing 
> semantics.

I think the default can be made final. This is because it is difficult to 
consider such complex "hack" operations as "features supported by the 
language." This is even considered a bug of some kind.

If more "realistic" code examples were available, the conclusion would be 
different.

At least, as far as I can currently understand, I don't think there is any need 
to consider backward compatibility with such "hacks".

Regards.

Saki
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Final anonymous classes

[Daniil Gentili]

Hi everyone,

I'd like to submit an RFC to add support for final anonymous classes.

This should also allow some additional opcache optimizations.

I've already prepared the implementation at 
https://github.com/php/php-src/pull/11126, what do you think?



Personally, I would have instead preferred the much cleaner approach of 
making *all* anonymous classes final by default, (preferrably) without 
offering the option to make them non-final.


However, I understand that this might be a little bit too restrictive 
for something that may have some valid usecases, even if extending 
anonymous classes currently requires some hack-ish workarounds with 
class_alias.



All in all, as per the title, I'd just like to add support for final 
anonymous classes (new final class {}), without changing any existing 
semantics.



What do you think?

Thanks,

Daniil Gentili.

Re: [PHP-DEV] Two new functions array_first() and array_last()

[Saki Takamachi]

I see now, that makes sense.

There is also a technique to make the return value `[$key => $value]` instead 
of just a value, but this loses simplicity.

Thanks.

Saki
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Two new functions array_first() and array_last()

[Michael Cordover]

On Tue, Oct 17, 2023, at 12:19, Saki Takamachi wrote:
>> What about a signature like:
>> 
>> ```php
>> array_first(array $array, mixed $value_if_missing = null);
>> ```
>> 
>> That would let you specify your own sentinel (or default) where appropriate, 
>> without losing the convenience of this function.
>
> This is a problem that should be addressed in your application.
>
> ```
> array_first($arr) ?? $initial
> ```
>
> I personally think we should make the effort to write it this way and 
> not have to support initial values ​​at the language level.

The problem Levi mentioned is that there's ambiguity in this construction: if 
the valid data domain for elements of `$arr` includes `null`, then you can't 
tell whether the null comes from the array being empty, or from its first value 
being null. In other words, there exists application code where using `??` in 
this way is unsuitable.

I can think of three approaches for dealing with this, resulting in application 
code like:

```
$value = array_first($arr, $default);

$value = count($arr) > 0 ? array_first($arr) : $default;

try {
  $value = array_first($arr);
} catch (OutOfBoundsException $e) {
  $value = $default;
}
```

I think the first of those - what I initially suggested - is the cleanest.

mjec

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Two new functions array_first() and array_last()

[Saki Takamachi]

> What about a signature like:
> 
> ```php
> array_first(array $array, mixed $value_if_missing = null);
> ```
> 
> That would let you specify your own sentinel (or default) where appropriate, 
> without losing the convenience of this function.

This is a problem that should be addressed in your application.

```
array_first($arr) ?? $initial
```

I personally think we should make the effort to write it this way and not have 
to support initial values ​​at the language level.

Regards.

Saki
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Two new functions array_first() and array_last()

[Michael Cordover]

On Tue, Oct 17, 2023, at 05:10, Levi Morrison via internals wrote:
> It's true that sentiment may have shifted in this time. However, a
> common argument at that time still stands: `null` is not a good
> sentintenal for failure because the value inside the array very well
> could have been null. 

What about a signature like:

```php
array_first(array $array, mixed $value_if_missing = null);
```

That would let you specify your own sentinel (or default) where appropriate, 
without losing the convenience of this function.

mjec

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Two new functions array_first() and array_last()

[Aimeos | Norbert Sendetzky]

On 17.10.23 17:16, Ken Guest wrote:

Having array_value_first and array_value_last to match the existing
array_key_first and array_key_last functions make sense, and would seem to
me to be more intuitive than function names that would not match that
scheme.


Please don't make things more complicated than they should be. Functions 
names should be short and memorable and array_first() and array_last() 
are perfect. No need for array_value_first() and array_value_last() just 
for the sake of matching with array_key_first() and array_key_last() 
functions.


Furthermore, returning NULL if the array contains no element is all we 
need in daily life because most often it doesn't matter if the array is 
empty or the first value is a NULL value. If it does, checking the array 
with empty() or using array_filter() is enough. No exceptions, warnings 
and notices please!


Always think of how you would use the functions in your own projects to 
write short and elegant code, not about all the special cases that 
should be handled separately.


Best,
Norbert



On Tue, 17 Oct 2023 at 10:41, Robert Landers 
wrote:


On Tue, Oct 17, 2023 at 11:37 AM Robert Landers
 wrote:


On Tue, Oct 17, 2023 at 11:34 AM Aleksander Machniak 

wrote:


On 17.10.2023 11:29, Robert Landers wrote:

$value = array_value_first($array, $key);
if($key === null) // handle error
else // do something with $value

You can also freely ignore the key, if you don't need it or care

about

error checking. That would save doing two function calls on the same
array, just to do some error checking.



Please, no. What's wrong with count() or empty()?

+1 for array_first() and array_last(). The only problem is probably a
big BC break. I myself have array_first() defined in my framework.

--
Aleksander Machniak
Kolab Groupware Developer[https://kolab.org]
Roundcube Webmail Developer  [https://roundcube.net]

PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php



Hey Aleksander,


Please, no. What's wrong with count() or empty()?


Nothing. Why not either one? You don't have to use the $key variable
and you can use count() or empty(), but for me personally, it makes a
lot of sense.


Ah, I just realized why it makes a lot of sense, and that is when
Fibers get involved. The value and key could change underneath you
from one function call to another.

$key = array_key_first($this-array);

// call something that suspends a fiber and results in $this->array
being mutated

$value = array_value_first($this->array);

// $value and $key may now point to two totally separate things.

I've been bitten by this with Fibers a few times now (or things very
similar to it).

Having a way to atomically get $key and $value would be a boon, not a
hindrance.

Robert Landers
Software Engineer
Utrecht NL

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php






--
Norbert Sendetzky

Aimeos GmbH
Rennbahnstr. 32
DE-22111 Hamburg

E-Mail: norb...@aimeos.com
Phone:  +49 40 8668 4492
Web: aimeos.com

Trade register: District court Hamburg HRB 143090
Managing director: Norbert Sendetzky
VAT ID: DE302287839

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Two new functions array_first() and array_last()

[Ken Guest]

Having array_value_first and array_value_last to match the existing
array_key_first and array_key_last functions make sense, and would seem to
me to be more intuitive than function names that would not match that
scheme.

On Tue, 17 Oct 2023 at 10:41, Robert Landers 
wrote:

> On Tue, Oct 17, 2023 at 11:37 AM Robert Landers
>  wrote:
> >
> > On Tue, Oct 17, 2023 at 11:34 AM Aleksander Machniak 
> wrote:
> > >
> > > On 17.10.2023 11:29, Robert Landers wrote:
> > > > $value = array_value_first($array, $key);
> > > > if($key === null) // handle error
> > > > else // do something with $value
> > > >
> > > > You can also freely ignore the key, if you don't need it or care
> about
> > > > error checking. That would save doing two function calls on the same
> > > > array, just to do some error checking.
> > > >
> > >
> > > Please, no. What's wrong with count() or empty()?
> > >
> > > +1 for array_first() and array_last(). The only problem is probably a
> > > big BC break. I myself have array_first() defined in my framework.
> > >
> > > --
> > > Aleksander Machniak
> > > Kolab Groupware Developer[https://kolab.org]
> > > Roundcube Webmail Developer  [https://roundcube.net]
> > > 
> > > PGP: 19359DC1 # Blog: https://kolabian.wordpress.com
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: https://www.php.net/unsub.php
> > >
> >
> > Hey Aleksander,
> >
> > > Please, no. What's wrong with count() or empty()?
> >
> > Nothing. Why not either one? You don't have to use the $key variable
> > and you can use count() or empty(), but for me personally, it makes a
> > lot of sense.
>
> Ah, I just realized why it makes a lot of sense, and that is when
> Fibers get involved. The value and key could change underneath you
> from one function call to another.
>
> $key = array_key_first($this-array);
>
> // call something that suspends a fiber and results in $this->array
> being mutated
>
> $value = array_value_first($this->array);
>
> // $value and $key may now point to two totally separate things.
>
> I've been bitten by this with Fibers a few times now (or things very
> similar to it).
>
> Having a way to atomically get $key and $value would be a boon, not a
> hindrance.
>
> Robert Landers
> Software Engineer
> Utrecht NL
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>


-- 
http://about.me/kenguest/

Re: [PHP-DEV] RFC Karma Request

[Ilija Tovilo]

Hi Yuya

RFC karma was granted, good luck with your RFC!

Ilija

On Tue, Oct 17, 2023 at 5:07 PM youkidearitai  wrote:
>
> Hi, internals.
>
> I writing to trim for multibyte support function, mb_trim, mb_ltrim
> and mb_rtrim.
> https://github.com/php/php-src/pull/12459
>
> Please give me RFC Karma.
> Username: youkidearitai
>
> Regards.
> Yuya
> --
> ---
> Yuya Hamada (tekimen)
> - https://tekitoh-memdhoi.info
> - https://github.com/youkidearitai
> -
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] RFC Karma Request

[youkidearitai]

Hi, internals.

I writing to trim for multibyte support function, mb_trim, mb_ltrim
and mb_rtrim.
https://github.com/php/php-src/pull/12459

Please give me RFC Karma.
Username: youkidearitai

Regards.
Yuya
-- 
---
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Two new functions array_first() and array_last()

[Robert Landers]

On Tue, Oct 17, 2023 at 11:37 AM Robert Landers
 wrote:
>
> On Tue, Oct 17, 2023 at 11:34 AM Aleksander Machniak  wrote:
> >
> > On 17.10.2023 11:29, Robert Landers wrote:
> > > $value = array_value_first($array, $key);
> > > if($key === null) // handle error
> > > else // do something with $value
> > >
> > > You can also freely ignore the key, if you don't need it or care about
> > > error checking. That would save doing two function calls on the same
> > > array, just to do some error checking.
> > >
> >
> > Please, no. What's wrong with count() or empty()?
> >
> > +1 for array_first() and array_last(). The only problem is probably a
> > big BC break. I myself have array_first() defined in my framework.
> >
> > --
> > Aleksander Machniak
> > Kolab Groupware Developer[https://kolab.org]
> > Roundcube Webmail Developer  [https://roundcube.net]
> > 
> > PGP: 19359DC1 # Blog: https://kolabian.wordpress.com
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
>
> Hey Aleksander,
>
> > Please, no. What's wrong with count() or empty()?
>
> Nothing. Why not either one? You don't have to use the $key variable
> and you can use count() or empty(), but for me personally, it makes a
> lot of sense.

Ah, I just realized why it makes a lot of sense, and that is when
Fibers get involved. The value and key could change underneath you
from one function call to another.

$key = array_key_first($this-array);

// call something that suspends a fiber and results in $this->array
being mutated

$value = array_value_first($this->array);

// $value and $key may now point to two totally separate things.

I've been bitten by this with Fibers a few times now (or things very
similar to it).

Having a way to atomically get $key and $value would be a boon, not a hindrance.

Robert Landers
Software Engineer
Utrecht NL

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Two new functions array_first() and array_last()

[Robert Landers]

On Tue, Oct 17, 2023 at 11:34 AM Aleksander Machniak  wrote:
>
> On 17.10.2023 11:29, Robert Landers wrote:
> > $value = array_value_first($array, $key);
> > if($key === null) // handle error
> > else // do something with $value
> >
> > You can also freely ignore the key, if you don't need it or care about
> > error checking. That would save doing two function calls on the same
> > array, just to do some error checking.
> >
>
> Please, no. What's wrong with count() or empty()?
>
> +1 for array_first() and array_last(). The only problem is probably a
> big BC break. I myself have array_first() defined in my framework.
>
> --
> Aleksander Machniak
> Kolab Groupware Developer[https://kolab.org]
> Roundcube Webmail Developer  [https://roundcube.net]
> 
> PGP: 19359DC1 # Blog: https://kolabian.wordpress.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

Hey Aleksander,

> Please, no. What's wrong with count() or empty()?

Nothing. Why not either one? You don't have to use the $key variable
and you can use count() or empty(), but for me personally, it makes a
lot of sense.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Two new functions array_first() and array_last()

[Aleksander Machniak]

On 17.10.2023 11:29, Robert Landers wrote:

$value = array_value_first($array, $key);
if($key === null) // handle error
else // do something with $value

You can also freely ignore the key, if you don't need it or care about
error checking. That would save doing two function calls on the same
array, just to do some error checking.



Please, no. What's wrong with count() or empty()?

+1 for array_first() and array_last(). The only problem is probably a 
big BC break. I myself have array_first() defined in my framework.


--
Aleksander Machniak
Kolab Groupware Developer[https://kolab.org]
Roundcube Webmail Developer  [https://roundcube.net]

PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Two new functions array_first() and array_last()

[Robert Landers]

On Tue, Oct 17, 2023 at 11:22 AM Lynn  wrote:
>
>
>
> On Tue, Oct 17, 2023 at 11:15 AM Robert Landers  
> wrote:
>>
>> On Tue, Oct 17, 2023 at 11:10 AM Levi Morrison via internals
>>  wrote:
>>
>> How is returning null any different than $array[0] on an empty array?
>> https://3v4l.org/>
>
> > > c) Two such functions were proposed and rejected during the
> > > array_key_first/last RFC
> > > (https://wiki.php.net/rfc/array_key_first_last)
> > >
> > > Yes, that was in 2018. At that time, functions like str_contains() or
> > > str_starts_with() wouldn't have even come into existence, just because
> > > there was an obscure way to do it without them. I believe we've moved
> > > on since then. Today we know how useful it is to use simple,
> > > easy-to-understand methods, both for programmers who write and read
> > > the code.
> >
> > It's true that sentiment may have shifted in this time. However, a
> > common argument at that time still stands: `null` is not a good
> > sentintenal for failure because the value inside the array very well
> > could have been null. This is not true for the keys. For me
> > personally, I think I would still vote no. I'm not entirely sure about
> > that, but that's how I would lean right now.
> >
> > As it stands, you'd have to write code along the lines of:
> >
> > ```php
> > $key = \array_key_first($array);
> > if ($key === null) {
> > // handle the failure
> > } else {
> > // success
> > $value = $array[$key];
> > }
> > ```
> >
> > Yes, it would be slightly nicer if we could do:
> >
> > ```php
> > $value = \array_first($array);
> > if ($value === null) {
> > // handle the failure
> > } else {
> > // success
> > }
> > ```
> >
> > But I fear in practice people will just omit the error checking.
> >
> > One way around that is to throw an exception. I'm not sure how I feel
> > about that, but I'll think about it.
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
>>
>> >K3gRs
>>
>> Currently, it just outputs a warning, but the result is `null`.
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: https://www.php.net/unsub.php
>>
>
> I'm okay with `null` being given back as it's the current behavior of 
> accessing the key as well, which is often checked through `$array[0] ?? 
> null`. Something like an `undefined` type could solve this problem, but 
> personally not a fan of this in Javascript. Maybe `array_has_first` or 
> something could be made, but honestly I would still just check for `null` 
> myself most likely.

Huh, that's a good observation Lynn. If I might suggest an API change
to `array_value_first` (and a similar one for array_value_last), it
would be this: `array_value_first(array $array, string|int|null &$key
= null): mixed` where you also get back the key. If you want to know
if null is an error or an actual value:

$value = array_value_first($array, $key);
if($key === null) // handle error
else // do something with $value

You can also freely ignore the key, if you don't need it or care about
error checking. That would save doing two function calls on the same
array, just to do some error checking.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Two new functions array_first() and array_last()

[Lynn]

On Tue, Oct 17, 2023 at 11:15 AM Robert Landers 
wrote:

> On Tue, Oct 17, 2023 at 11:10 AM Levi Morrison via internals
>  wrote:
>
> How is returning null any different than $array[0] on an empty array?
> https://3v4l.org/ >

> > c) Two such functions were proposed and rejected during the
> > array_key_first/last RFC
> > (https://wiki.php.net/rfc/array_key_first_last)
> >
> > Yes, that was in 2018. At that time, functions like str_contains() or
> > str_starts_with() wouldn't have even come into existence, just because
> > there was an obscure way to do it without them. I believe we've moved
> > on since then. Today we know how useful it is to use simple,
> > easy-to-understand methods, both for programmers who write and read
> > the code.
>
> It's true that sentiment may have shifted in this time. However, a
> common argument at that time still stands: `null` is not a good
> sentintenal for failure because the value inside the array very well
> could have been null. This is not true for the keys. For me
> personally, I think I would still vote no. I'm not entirely sure about
> that, but that's how I would lean right now.
>
> As it stands, you'd have to write code along the lines of:
>
> ```php
> $key = \array_key_first($array);
> if ($key === null) {
> // handle the failure
> } else {
> // success
> $value = $array[$key];
> }
> ```
>
> Yes, it would be slightly nicer if we could do:
>
> ```php
> $value = \array_first($array);
> if ($value === null) {
> // handle the failure
> } else {
> // success
> }
> ```
>
> But I fear in practice people will just omit the error checking.
>
> One way around that is to throw an exception. I'm not sure how I feel
> about that, but I'll think about it.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php

> >K3gRs 
>
> Currently, it just outputs a warning, but the result is `null`.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
I'm okay with `null` being given back as it's the current behavior of
accessing the key as well, which is often checked through `$array[0] ??
null`. Something like an `undefined` type could solve this problem, but
personally not a fan of this in Javascript. Maybe `array_has_first` or
something could be made, but honestly I would still just check for `null`
myself most likely.

Re: [PHP-DEV] Two new functions array_first() and array_last()

[Robert Landers]

On Tue, Oct 17, 2023 at 11:10 AM Levi Morrison via internals
 wrote:
>
> > c) Two such functions were proposed and rejected during the
> > array_key_first/last RFC
> > (https://wiki.php.net/rfc/array_key_first_last)
> >
> > Yes, that was in 2018. At that time, functions like str_contains() or
> > str_starts_with() wouldn't have even come into existence, just because
> > there was an obscure way to do it without them. I believe we've moved
> > on since then. Today we know how useful it is to use simple,
> > easy-to-understand methods, both for programmers who write and read
> > the code.
>
> It's true that sentiment may have shifted in this time. However, a
> common argument at that time still stands: `null` is not a good
> sentintenal for failure because the value inside the array very well
> could have been null. This is not true for the keys. For me
> personally, I think I would still vote no. I'm not entirely sure about
> that, but that's how I would lean right now.
>
> As it stands, you'd have to write code along the lines of:
>
> ```php
> $key = \array_key_first($array);
> if ($key === null) {
> // handle the failure
> } else {
> // success
> $value = $array[$key];
> }
> ```
>
> Yes, it would be slightly nicer if we could do:
>
> ```php
> $value = \array_first($array);
> if ($value === null) {
> // handle the failure
> } else {
> // success
> }
> ```
>
> But I fear in practice people will just omit the error checking.
>
> One way around that is to throw an exception. I'm not sure how I feel
> about that, but I'll think about it.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

How is returning null any different than $array[0] on an empty array?
https://3v4l.org/K3gRs

Currently, it just outputs a warning, but the result is `null`.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Two new functions array_first() and array_last()

[Levi Morrison via internals]

> c) Two such functions were proposed and rejected during the
> array_key_first/last RFC
> (https://wiki.php.net/rfc/array_key_first_last)
>
> Yes, that was in 2018. At that time, functions like str_contains() or
> str_starts_with() wouldn't have even come into existence, just because
> there was an obscure way to do it without them. I believe we've moved
> on since then. Today we know how useful it is to use simple,
> easy-to-understand methods, both for programmers who write and read
> the code.

It's true that sentiment may have shifted in this time. However, a
common argument at that time still stands: `null` is not a good
sentintenal for failure because the value inside the array very well
could have been null. This is not true for the keys. For me
personally, I think I would still vote no. I'm not entirely sure about
that, but that's how I would lean right now.

As it stands, you'd have to write code along the lines of:

```php
$key = \array_key_first($array);
if ($key === null) {
// handle the failure
} else {
// success
$value = $array[$key];
}
```

Yes, it would be slightly nicer if we could do:

```php
$value = \array_first($array);
if ($value === null) {
// handle the failure
} else {
// success
}
```

But I fear in practice people will just omit the error checking.

One way around that is to throw an exception. I'm not sure how I feel
about that, but I'll think about it.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php