Re: [PHP-DEV][VOTE] Add grapheme_levenshtein function

2025-04-15 Thread youkidearitai
2025年4月1日(火) 13:39 youkidearitai : > > Hi, internals. > > I started vote to RFC grapheme_levenshtein > RFC: https://wiki.php.net/rfc/grapheme_levenshtein > > Voting end is 2025-04-16 00:00:00(UTC+0). > > Regards > Yuya > > -- > --- > Yuya Hamada (tekimen) > - https://tekitoh

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

2025-04-15 Thread Máté Kocsis
Hi Tim, > Perhaps the correct solution would be to offer only the non-raw methods > for WHATWG URL and to not attempt any additional percent-decoding there? > My reasoning is that the WHATWG URL is a living standard anyways, so > trying to add additional semantics on top will result in sadness. M

Re: [PHP-DEV] Re: [RFC] [Discussion] Never parameters

2025-04-15 Thread Andreas Hennings
On Tue, 15 Apr 2025 at 20:59, Daniel Scherzer wrote: > > On Tue, Apr 8, 2025 at 6:40 PM Daniel Scherzer > wrote: >> >> >> Since a lot of the discussion seems to be around static analysis and whether >> there is a real use case for this, I wanted to share another use case I just >> came across:

[PHP-DEV] Re: [RFC] [Discussion] Never parameters

2025-04-15 Thread Daniel Scherzer
On Tue, Apr 8, 2025 at 6:40 PM Daniel Scherzer wrote: > > Since a lot of the discussion seems to be around static analysis and > whether there is a real use case for this, I wanted to share another use > case I just came across: in the `thephpleague/commonmark` package, > different renderers are

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

2025-04-15 Thread Ignace Nyamagana Butera
Perhaps the correct solution would be to offer only the non-raw methods for WHATWG URL and to not attempt any additional percent-decoding there? My reasoning is that the WHATWG URL is a living standard anyways, so trying to add additional semantics on top will result in sadness. My understandin

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

2025-04-15 Thread Tim Düsterhus
Hi Am 2025-04-13 14:10, schrieb Máté Kocsis: namespace Uri { class InvalidUriException extends \Uri\UriException { } } namespace Uri\WhatWg { class InvalidUrlException extends \Uri\InvalidUriException { /** @var list */

Re: [PHP-DEV] Closure::getCurrent() for recursion

2025-04-15 Thread Rowan Tommins [IMSoP]
On 15/04/2025 11:49, Jorg Sowa wrote: I gave this example only to point out that this case should be mentioned in the RFC to dispel doubts what's intended and eventually put such test case into the PR. Sure, but there was a mistake in your example - Closure::current(10) should be Closure::cu

Re: [PHP-DEV] Closure::getCurrent() for recursion

2025-04-15 Thread Jorg Sowa
I gave this example only to point out that this case should be mentioned in the RFC to dispel doubts what's intended and eventually put such test case into the PR. Kind regards, Jorg

Re: [PHP-DEV] New max_memory_limit INI setting

2025-04-15 Thread Jordi Boggiano
On 14.04.2025 14:41, Ilija Tovilo wrote: One open question is whether exceeding the max_memory_limit should also set memory_limit to max_memory_limit in addition to warning, giving the subsequent operation a higher chance not to straight out OOM error. Let me know if you have a preference in that

Re: [PHP-DEV] Closure::getCurrent() for recursion

2025-04-15 Thread Rowan Tommins [IMSoP]
On 15 April 2025 00:01:18 BST, Krinkle wrote: >Eg: > >$a = function ($a) { > $aFn = Closure::current(...); > $aFn(4) === Closure::current(4); >}; I think there's some confusion on this thread; as I understand it, the proposal is not for a magic function to *call* the current closure, but a w