Re: [PHP-DEV] Deprecation of the formats DATE_ISO8601 and DATE_RFC7231

2023-06-02 Thread Niels Dossche
On 6/3/23 00:28, Jorg Sowa wrote: > I would write RFC anyway to check the reception, but I need Karma to do it. > Could I ask someone for it? > You'll need to register on the wiki, and send an email to internals in which you say your wiki name. Kind regards Niels -- PHP Internals - PHP

Re: [PHP-DEV] Deprecation of the formats DATE_ISO8601 and DATE_RFC7231

2023-06-02 Thread Jorg Sowa
> In my opinion, since it isn't, and likely never was, a legal ISO8601 > string, it's a no-brainer that it should be deprecated. (it's at least > been illegal since iso8601:2004 released in 2004) I thought the same when I started the discussion. It's not good promotion for PHP, when every mention

Re: [PHP-DEV] RFC [Discussion]: Marking overridden methods (#[\Override])

2023-06-02 Thread Niels Dossche
Hi Tim On 5/11/23 18:37, Tim Düsterhus wrote: > Hi > > I'm now opening discussion for the RFC "Marking overridden methods > (#[\Override])": > > > > RFC: Marking overridden methods (#[\Override]) > https://wiki.php.net/rfc/marking_overriden_methods > > Proof of concept implementation is

Re: [PHP-DEV] Deprecation of the formats DATE_ISO8601 and DATE_RFC7231

2023-06-02 Thread Hans Henrik Bergan
DATE_ISO8601 doesn't have to be removed anytime soon, but no new code should be written using that constant, thus an E_DEPRECATED is warranted. Is anyone really arguing against that statement? On Tue, 30 May 2023 at 18:26, Hans Henrik Bergan wrote: > > >In my opinion, deprecating this does not

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

2023-06-02 Thread Máté Kocsis
Hi Claude, The very risk is that the programmer must be aware that the return > convention has changed. Recall that not everyone run static analysers, > especially for such a trivial migration, and that not every code is > statically analysable (e.g.. `$foo->$bar()`). > I hope that I don't sound

Re: [PHP-DEV] Proposal: addition of array_find() and array_find_key() functions

2023-06-02 Thread Pierre
Le 02/06/2023 à 10:57, Janusz Szczypka a écrit : You are right about speed penalty for using those functions over simple loops, however if we would stick to that point of view, we should deprecate and remove array_filter, array_map, array_walk, array_u... I'm not sure they deserve

Re: [PHP-DEV] Proposal: addition of array_find() and array_find_key() functions

2023-06-02 Thread Janusz Szczypka
W dniu 2.06.2023 o 03:24, Hans Henrik Bergan pisze: 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? array_filter is guaranteed to always return an array and we should not change it. Flags are used

Re: [PHP-DEV] Proposal: addition of array_find() and array_find_key() functions

2023-06-02 Thread Janusz Szczypka
W dniu 2.06.2023 o 02:14, Casper Langemeijer pisze: 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

Re: [PHP-DEV] RFC Karma

2023-06-02 Thread Tim Düsterhus
Hi On 6/2/23 00:51, Nick Humphries wrote: 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. The folks handing out the RFC karma would need to know your Wiki username to do so. Best regards Tim