On Sat, Nov 4, 2023 at 11:40 AM Tim Düsterhus wrote:
> Hi
>
> On 11/3/23 21:51, Jakub Zelenka wrote:
> >> The main reason I would like to see this deprecated is not the fact that
> >> it's returning a less precise value compared to getrusage, but rather
> >> because it's returning a value that ca
Hi
On 11/3/23 21:51, Jakub Zelenka wrote:
The main reason I would like to see this deprecated is not the fact that
it's returning a less precise value compared to getrusage, but rather
because it's returning a value that cannot be interpreted in any way
from pure PHP.
So if the constant is add
On Fri, Nov 3, 2023 at 6:49 PM wrote: added in php 8.3,
that's why I couldn't find it in the docs :)
>
> Respectfully, I will still be editing the deprecations RFC anyway to see
> if the voting passes.
>
>
Hmm, didn't you say this previously:
> The main reason I would like to see this deprecated
Hi,
> It is exposed:
> https://github.com/php/php-src/blob/66e2aa725564c2221ace7a26628afe3957f28237/ext/posix/posix.c#L1232-L1241
>
Welp completely missed that, my bad, it was added in php 8.3, that's why I
couldn't find it in the docs :)
Respectfully, I will still be editing the deprecations R
On Thu, Nov 2, 2023 at 11:11 PM wrote:
> 1) Not all POSIX functions are currently exposed by the POSIX extension,
> sysconf being one of the missing ones (with IMO no good reason to add it)
>
It is exposed:
https://github.com/php/php-src/blob/66e2aa725564c2221ace7a26628afe3957f28237/ext/posix/po
Hi
On 11/3/23 00:14, dan...@daniil.it wrote:
This deprecation appears to be sufficiently simple that it can likely be
included in the bulk deprecation RFC for PHP 8.4:
https://wiki.php.net/rfc/deprecations_php_8_4
That would be super nice, who should I ping before editing the page?
I'd sa
Hi,
> This deprecation appears to be sufficiently simple that it can likely be
> included in the bulk deprecation RFC for PHP 8.4:
>
> https://wiki.php.net/rfc/deprecations_php_8_4
That would be super nice, who should I ping before editing the page?
Regards,
Daniil Gentili
Hi, I would like to echo the sentiment expressed by Tim earlier in another
subthread:
>If a function cannot be safely or correctly used at all, then it shouldn't
>exist, especially if there are working alternatives [1].
>
>Expecting users to find a warning in the docs to learn that they should
Hi,
On Tue, Oct 17, 2023 at 6:39 PM Daniil Gentili wrote:
> 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.
>
The times() is defined by POSIX and I don't see a reason why it couldn't be
exposed even though there is a
Hi
On 10/17/23 19:39, Daniil Gentili wrote:
I would like to submit an RFC (and related PR) to deprecate posix_times
for PHP 8.4, removing it for PHP 9.
[…]
Waiting for feedback, kind regards,
This deprecation appears to be sufficiently simple that it can likely be
included in the bulk depre
Hi
On 10/18/23 09:00, Christian Schneider wrote:
My question here would be: Is there sufficient reason to remove this function
and introduce a BC break, i.e. is the implementation code hard to maintain or
does the function cause security issues?
Unless that is the case I'd leave it unchanged
Hi,
As listed in my original thread, I think that offering posix_times
without offering sysconf would be like offering a version of the
microtime function, which returns a value divided by a *undocumented and
unexposed divider that changes in each patch version of PHP*.
The main reason I wou
Am 17.10.2023 um 19:39 schrieb Daniil Gentili :
> I would like to submit an RFC (and related PR) to deprecate posix_times for
> PHP 8.4, removing it for PHP 9.
My question here would be: Is there sufficient reason to remove this function
and introduce a BC break, i.e. is the implementation code
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 start
14 matches
Mail list logo