Hello, Rowan!
> I don't have time to dig into the details of this draft at the moment,
but will say that a vote in two weeks is not at all realistic.
I just used the Flow from the Wiki. :)
> My only other comment at a very quick glance is that I see the Context
section is still included, and stil
Release Manager Duties, see: https://externals.io/message/127025#127131
On 17.04.2025 at 17:23, Volker Dusch wrote:
> Release Manager Duties, see: https://externals.io/message/127025#127131
Your account request has been approved. Congrats for being one of the
new RMs!
Christoph
Hi
On 4/17/25 22:47, Paul M. Jones wrote:
As such, the _InvalidUriException_ would better extend from _LogicException_.
No. There is a de facto policy of “not using SPL exceptions in new
code”. The replacement for LogicException is the Error hierarchy.
Also, as you quoted yourself, LogicExc
Hi
Am 2025-04-07 09:14, schrieb Rowan Tommins [IMSoP]:
I think a function for "string is zero length or contains only
whitespace" would potentially be useful
And for that one it would need to be defined what whitespace is. Is it
just the ASCII whitespace characters? Is it Unicode whitespace?
Hi Maté and all,
A one-off comment about the exceptions:
The RFC posits that _Uri\UriException_ extends _Exception_, and
_Uri\InvalidUriException_ extends _UriException_.
However, pre-existing userland solutions to the URI problem lean more heavily
on the native PHP _InvalidArgumentException_,
> On Apr 17, 2025, at 15:58, Tim Düsterhus wrote:
>
> Hi
>
> On 4/17/25 22:47, Paul M. Jones wrote:
>> As such, the _InvalidUriException_ would better extend from _LogicException_.
>
> No. There is a de facto policy of “not using SPL exceptions in new code”. The
> replacement for LogicExcep
Hi
On 4/17/25 23:14, Paul M. Jones wrote:
On 4/17/25 22:47, Paul M. Jones wrote:
As such, the _InvalidUriException_ would better extend from _LogicException_.
No. There is a de facto policy of “not using SPL exceptions in new code”. The
replacement for LogicException is the Error hierarchy.
Hi
Am 2025-04-16 02:40, schrieb youkidearitai:
The RFC for add grapheme_levenshtein function has been accepted.
(Yes 12 / No 0)
Thank you very much for voting.
I will go to implementation.
Great, thank you! I noticed that while you updated the status in the RFC
itself, you did not update the
Hi
Am 2025-04-15 23:55, schrieb Máté Kocsis:
This was one of my (unspoken) ideas as well. I used to think there must
have been a correct logic
for percent-decoding of WHATWG components, but if none of us can come
up
with a sensible
idea, then it's best not to try it, I agree.
Sweet. I believ
Hi
Am 2025-04-15 10:13, schrieb Jordi Boggiano:
I'd say absolutely yes it should respect the requested memory limit as
much as possible.
Especially when setting memory_limit to -1 you'd definitely want this
to mean "use the max allowed memory limit" and perhaps even skip the
warning in that
> The link in Patches and Tests is currently giving a 404 Not Found.
> Can you update the link to your proof of concept implementation?
Thank you for pointing that out. I’ve corrected the link.
https://github.com/EdmondDantes/php-src/tree/async/ext/async
I still have one last question regarding the RFC3986 URI path component.
Currently the path is nullable but according to the RFC the path can not be
nullable
According to the RFC the path can have up to 5 ABNF representation
> path = path-abempty ; begins with "/" or is empty
Hello, Vincent.
> The `spawn` keyword might disqualify this rfc, i talked to alot of php
devs about this rfc and they all had a similar complaint about the keyword,
maybe a keyword choice poll might help when the rfc voting goes live.
To have any kind of vote, we need multiple options. The keywor
Hi,
Tim Düsterhus ezt írta (időpont: 2025. ápr. 17., Cs,
9:22):
> Hi
>
> Am 2025-04-15 23:55, schrieb Máté Kocsis:
> > This was one of my (unspoken) ideas as well. I used to think there must
> > have been a correct logic
> > for percent-decoding of WHATWG components, but if none of us can come
On 17 April 2025 09:54:26 BST, Edmond Dantes wrote:
>> My only other comment at a very quick glance is that I see the Context
>section is still included, and still has most of its complexity.
>Almost every section of the RFC has a "Motivation" subsection, which
>explains why a particular tool i
Hi all,
The polls have closed, and Derick’s scripts have tallied the votes [1],
Our “rookie" PHP 8.5 release managers are:
- Volker Dusch
- Daniel Scherzer
Our "veteran” is the PHP 8.2 & PHP 8.3 release manager Pierrick Charron,
Volker and Daniel you are in a good hands!
Further steps are desc
Here are list of the problems i saw in this RFC:
1.) The `spawn` keyword might disqualify this rfc, i talked to alot of php
devs about this rfc and they all had a similar complaint about the keyword,
maybe a keyword choice poll might help when the rfc voting goes live.
2.) This whole rfc seem a l
Hi Ignace,
> Uh, this is something that I also forgot to sync between the
> implementation and the RFC. I also recently found out that
> the get*Path() methods should be non-nullable for both classes, so I
> recently fixed them. Sorry for the confusion!
>
Actually, I realized after checking the
Hi Ignace,
> Currently the path is nullable but according to the RFC the path can not
> be nullable
> According to the RFC the path can have up to 5 ABNF representation
>
Uh, this is something that I also forgot to sync between the implementation
and the RFC. I also recently found out that
the g
20 matches
Mail list logo
