Re: [PHP-DEV] [RFC][Discussion] Policy release process update

Hi, On Fri, May 9, 2025 at 1:09 PM Tim Düsterhus wrote: > Hi > > Am 2025-05-09 12:47, schrieb Jakub Zelenka: > > I'd like to start discussion for some release process updates defined > > in > > the following RFC / linked PR: > > > > RFC: https://wiki.php.net/rfc/policy-release-process-update > >

Re: [PHP-DEV] [RFC][Discussion] Policy release process update

Hi Am 2025-05-09 12:47, schrieb Jakub Zelenka: I'd like to start discussion for some release process updates defined in the following RFC / linked PR: RFC: https://wiki.php.net/rfc/policy-release-process-update Policy PR: https://github.com/php/policies/pull/19 Thank you. The changes seem to

Re: [PHP-DEV] Initial discussion - more deprecation options

Hi Daniel On Thu, May 8, 2025 at 5:48 PM Daniel Scherzer wrote: > > So this example would emit deprecation warnings on all getting and setting > operations, but I was thinking that they would *not* be emitted when being > accessed from within the same class (private scope). Consider a project t

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

Hi all, > On May 7, 2025, at 17:02, Gina P. Banyard wrote: > > On Wednesday, 7 May 2025 at 20:20, Paul M. Jones wrote: > >> I am on record as wanting very much to see some decent web-centric objects >> in core PHP (Request, Response, Uri/Url, etc). >> >> To my chagrin, despite the fact that

Re: [PHP-DEV] Initial discussion - more deprecation options

On Thu, May 8, 2025 at 8:38 AM Tim Düsterhus wrote: > Hi > > Am 2025-05-07 21:43, schrieb Niels Dossche: > > Definitely NAK on deprecating properties, which has the potential of > > adding lots of overhead. > > FWIW: Deprecating properties is already possibly by means of deprecating > a property

Re: [PHP-DEV] Modules, again.

On Wed, May 7, 2025, at 3:51 PM, Michael Morris wrote: >> The main exception, as you have pointed out, is plugin architectures >> like WordPress, where the plugin might want to "privately" use some >> library without impacting the host application and other plugins. > > It's not just WordPress.

Re: [PHP-DEV] Re: RFC: Nested Classes

Hi Am 2025-05-07 19:15, schrieb Rowan Tommins [IMSoP]: There are three "platform dependency" pseudo-packages available for packages to depend on different aspects of Composer's version: https://getcomposer.org/doc/articles/composer-platform-dependencies.md If these didn't seem suitable, they c

RE: External Message: Re: [PHP-DEV] [RFC] [Discussion] Minor version compatibility

> -Original Message- > You consider it pressure, I consider it communicating how I feel about > contributing to the project, which has already been less enjoyable than before > for a while. > > > Best regards, > > Gina P. Banyard Just a quick note, your contributions to the project are

Re: [PHP-DEV] [RFC] [Discussion] Minor version compatibility

Am 08.05.2025 um 00:36 schrieb Gina P. Banyard : >> If this would have been done without warning phase then it would be a >> blocker for upgrading to PHP 8.4, now filtering this warning is enough while >> the packages are being updated. > > Comparing a core language change to be the same level a

Re: [PHP-DEV] [RFC] [Discussion] Minor version compatibility

On Wednesday, 30 April 2025 at 13:16, Christian Schneider wrote: > Am 27.04.2025 um 20:22 schrieb Gina P. Banyard intern...@gpb.moe: > > > I fundamentally reject the concept of this RFC to restrict our ability to > > do input validation. > > > I am sorry but I fail to see how the RFC restric

Re: [PHP-DEV] Modules, again.

On 7 May 2025 21:51:29 BST, Michael Morris wrote: >On Wed, May 7, 2025 at 3:24 PM Rowan Tommins [IMSoP] >wrote: > >Other libraries have the means to import into a namespace because their >namespaces aren't just a quick and dirty string replacement. I've even >proposed such a long, long time a

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

On Wednesday, 7 May 2025 at 20:20, Paul M. Jones wrote: > Hi Maté and all, > > > On May 5, 2025, at 16:36, Máté Kocsis kocsismat...@gmail.com wrote: > > > > Hello Internals, > > > > After more than a hundred emails refining even the tiniest details, we have > > reached a point where I'd like

Re: [PHP-DEV] Modules, again.

On Wed, May 7, 2025 at 3:24 PM Rowan Tommins [IMSoP] wrote: > > Problem number 2 is what you seem to be trying to address. > The main thing, yes. This solution incidentally solves class privacy issues several unrelated and failed RFC's have addressed, including Nested Classes which is currently

Re: [PHP-DEV] Initial discussion - more deprecation options

On 07/05/2025 22:02, Tim Düsterhus wrote: > Hi > > Am 2025-05-07 21:43, schrieb Niels Dossche: >> Definitely NAK on deprecating properties, which has the potential of adding >> lots of overhead. > > FWIW: Deprecating properties is already possibly by means of deprecating a > property hook. I gu

Re: [PHP-DEV] Initial discussion - more deprecation options

Hi Am 2025-05-07 21:43, schrieb Niels Dossche: Definitely NAK on deprecating properties, which has the potential of adding lots of overhead. FWIW: Deprecating properties is already possibly by means of deprecating a property hook. I guess this is an acceptable workaround to not require a ded

Re: [PHP-DEV] Initial discussion - more deprecation options

Hi Definitely NAK on deprecating properties, which has the potential of adding lots of overhead. Note also that cache slot merging (during compact_literals optimizer pass) when opcache is active may dodge the deprecation notice, and I don't want more VM workarounds for then doing this anyway.

Re: [PHP-DEV] Initial discussion - more deprecation options

On Wed, May 7, 2025, at 12:50 PM, Daniel Scherzer wrote: > Hi internals > > I'd like to start off some preliminary discussion about expanding the places > that `#[\Deprecated]` can be used, and more widely how userland code can have > the engine trigger deprecation warnings (rather than just manual

Re: [PHP-DEV] Modules, again.

On 04/05/2025 08:34, Michael Morris wrote: PHP has no way of dealing with userland code trying to write to the same entry on the symbol tables.  Namespaces are a workaround of this and combined with autoloaders they've yielded the package environments we currently have (usually composer), but a

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

Hi Maté and all, > On May 5, 2025, at 16:36, Máté Kocsis wrote: > > Hello Internals, > > After more than a hundred emails refining even the tiniest details, we have > reached a point where I'd like to call for a vote. > I know that the new API still doesn't support many use-cases, it still has

Re: [PHP-DEV] Modules, again.

On Wed, May 7, 2025 at 10:59 AM Larry Garfield wrote: > > So it's not really giving private symbols. It's not even blocking access > to anything, since it can still just be included or autoloaded. What > you're proposing is really just an optional loading facade (the real kind > of facade) that

Re: [PHP-DEV] Re: RFC: Nested Classes

On 07/05/2025 14:10, Tim Düsterhus wrote: And rewrite all references inside of `Foo` to `Foo$Bar` (using Java's name mangling). This is effectively what Ilija's proposal for file-private classes did: https://externals.io/message/126331#126337. I think this would also be nicer on the autoloading

Re: [PHP-DEV] Re: RFC: Nested Classes

On 07/05/2025 14:18, Tim Düsterhus wrote: I don't think it is currently possible to define a minimum composer version as part of a package’s dependencies. There are three "platform dependency" pseudo-packages available for packages to depend on different aspects of Composer's version: https

Re: [PHP-DEV] Re: RFC: Nested Classes

Hi Am 2025-05-06 21:33, schrieb Rowan Tommins [IMSoP]: The classes that you'll need to be aware of will exist whether this feature is added or not, and you'll already need to avoid conflicting with them - usually by simply avoiding the main namespace prefix of the library. If this feature wa

Re: [PHP-DEV] Modules, again.

On Tue, May 6, 2025, at 1:33 AM, Michael Morris wrote: > Resetting and moving the proposal writeup to a github hosted markdown > file here: > https://github.com/michael-lloyd-morris/php-modules-rfc/blob/main/php-modules.md >> From your follow up statements, it seems that what you are proposing i

Re: [PHP-DEV] Re: RFC: Nested Classes

Hi Am 2025-05-06 22:04, schrieb Rob Landers: I think these are fundamental problems (if they are a problem at all) with how PHP currently does namespaces and names. I don't think that this is a fundamental problem of namespaces and names. Ilija solved the naming conflict issue in his file-pri

Re: [PHP-DEV] Re: RFC: Nested Classes

On Sun, May 4, 2025, at 15:52, Tim Düsterhus wrote: > Hi > > On 4/30/25 12:51, Rowan Tommins [IMSoP] wrote: > > I think you are insisting on a different definition of "private" for nested > > classes than exists anywhere else in the language, and one that I've not > > seen evidence of in any oth

Re: [PHP-DEV] Re: RFC: Nested Classes

On 4 May 2025 14:52:23 BST, "Tim Düsterhus" wrote: >> It's also not a new problem: PHP doesn't enforce a file and directory >> layout, and libraries can and do define things "inside" each other's >> namespaces. When declaring a class, you have to be aware of whether a class >> with the same

Re: [PHP-DEV] Modules, again.

Resetting and moving the proposal writeup to a github hosted markdown file here: https://github.com/michael-lloyd-morris/php-modules-rfc/blob/main/php-modules.md On Mon, May 5, 2025 at 12:44 AM Larry Garfield wrote: > > > So before you get indignant and call me a liar ("You're 4 for 4 on > false

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

Hello Internals, After more than a hundred emails refining even the tiniest details, we have reached a point where I'd like to call for a vote. I know that the new API still doesn't support many use-cases, it still has missing pieces, but now it includes a cohesive set of functionality that could

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

Hi Paul, I would not presume that the dedicated value objects are what "makes the > [Rowbot] library much slower" than the RFC -- instead, my first intuition is that the *parsing* operations are slower in userland > than in C, and are primarily responsible for the comparative slowness. Speedwise

Re: [PHP-DEV] Modules, again.

Hello, Michael. Thank you very much for your work. It's very interesting. Let me look at this idea from an architectural perspective. Did I understand correctly from the text that: * Modules control which entities are public and which are not? * During import, we specify which entities we want

Re: [PHP-DEV] Modules, again.

On Sun, 4 May 2025 at 17:31, Michael Morris wrote: > > > On Sun, May 4, 2025 at 7:06 AM Arvids Godjuks > wrote: > >> >> It ended exactly how my first judging brain wave thought it would go - >> this whole thing is about fixing WordPress by changing the language. Plain >> and simple. >> >> > That

Re: [PHP-DEV] Modules, again.

> On 5 May 2025, at 04:18, Larry Garfield wrote: > > On Sun, May 4, 2025, at 2:34 AM, Michael Morris wrote: >> It's been 9 months. Been researching, working on other projects, >> mulling over >> points raised the last time I brought this up. And at the moment I >> don't think >> PHP 8.5 is

Re: [PHP-DEV] Modules, again.

On Sun, May 4, 2025, at 5:40 PM, Michael Morris wrote: > On Sun, May 4, 2025 at 5:38 PM Larry Garfield wrote: >> >> > PHP Code >> > --- >> > >> > namespace MyModule; >> > >> > yield function sum(a, b) { return a + b; } >> > >> >

Re: [PHP-DEV] Modules, again.

On Sun, May 4, 2025 at 5:38 PM Larry Garfield wrote: > > > PHP Code > --- > > > > namespace MyModule; > > > > yield function sum(a, b) { return a + b; } > > > > > --

Re: [PHP-DEV] Modules, again.

On Sun, May 4, 2025, at 4:25 PM, Michael Morris wrote: > On Sun, May 4, 2025 at 5:19 PM Larry Garfield wrote: >> On Sun, May 4, 2025, at 2:34 AM, Michael Morris wrote: >> > It's been 9 months. Been researching, working on other projects, >> > mulling over >> > points raised the last time I broug

Re: [PHP-DEV] Modules, again.

On Sun, May 4, 2025 at 5:19 PM Larry Garfield wrote: > On Sun, May 4, 2025, at 2:34 AM, Michael Morris wrote: > > It's been 9 months. Been researching, working on other projects, > > mulling over > > points raised the last time I brought this up. And at the moment I > > don't think > > PHP 8.5 is

Re: [PHP-DEV] Modules, again.

On Sun, May 4, 2025, at 2:34 AM, Michael Morris wrote: > It's been 9 months. Been researching, working on other projects, > mulling over > points raised the last time I brought this up. And at the moment I > don't think > PHP 8.5 is in its final weeks so this isn't a distraction for that. > T

Re: [PHP-DEV] Modules, again.

On Sun, May 4, 2025 at 7:06 AM Arvids Godjuks wrote: > > It ended exactly how my first judging brain wave thought it would go - > this whole thing is about fixing WordPress by changing the language. Plain > and simple. > > That is a lie. Go back and read again - I discuss how this will improve Dr

Re: [PHP-DEV] Re: RFC: Nested Classes

Hi On 4/30/25 12:51, Rowan Tommins [IMSoP] wrote: I think you are insisting on a different definition of "private" for nested classes than exists anywhere else in the language, and one that I've not seen evidence of in any other similar language either. It seems you want members to be "hidden"

Re: [PHP-DEV] Modules, again.

Hi! On Sun, May 4, 2025 at 8:08 AM Arvids Godjuks wrote: > > > On Sun, 4 May 2025 at 10:36, Michael Morris wrote: > >> It's been 9 months. Been researching, working on other projects, mulling >> over >> points raised the last time I brought this up. And at the moment I don't >> think >> PHP 8.5

[PHP-DEV] Re:  Re: [PHP-DEV] Modules, again.

On Sun, 4 May 2025 at 14:57, Jochen Schultz wrote: > > > Am 04.05.25, 13:07 schrieb Arvids Godjuks : >> >> >> >> On Sun, 4 May 2025 at 10:36, Michael Morris wrote: >> >>> It's been 9 months. Been researching, working on other projects, mulling >>> over >>> points raised the last time I brought t

Aw: Re: [PHP-DEV] Modules, again.

Am 04.05.25, 13:07 schrieb Arvids Godjuks gmail.com>: On Sun, 4 May 2025 at 10:36, Michael Morris wrote:It's been 9 months. Been researching, working on other projects, mulling over points raised the last time I brought this up. And at the moment I don't think PHP 8.5 is in its

Re: [PHP-DEV] Modules, again.

On Sun, 4 May 2025 at 10:36, Michael Morris wrote: > It's been 9 months. Been researching, working on other projects, mulling > over > points raised the last time I brought this up. And at the moment I don't > think > PHP 8.5 is in its final weeks so this isn't a distraction for that. The > prev

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

Hey Ignace, > I see you updated the RFC but I believe there's still some errors in the > example: > $url = Uri\WhatWg\Url::parse("/foo", ".com"); // Throws > Uri\WhatWg\InvalidUrlException because of $baseUri > After following the suggestion of Tim, I changed the type of the $baseUrl parameters

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

Hi Ignace, Why can't the Url::resolve method also expose the `$errors` parameter like > the constructor and the parse static method ? As far as I understand it > nothing prevents the API from exposing the errors during URI resolution > which is a proxy method for the constructor call just like the

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

Hi Ignace, I have just added the SensitiveParameter attribute to the Uri\Rfc3986\Uri::withUserInfo() and Uri\WhatWg\Url::withPassword() methods. > Reading the WHATWG URL specification and checking how > >- Chrome, >- Firefox >- and even https://github.com/TRowbotham/URL-Parser > > >

Re: [PHP-DEV] Deferred backtrace generation algorithm.

Hello Bob. > So you effectively will have to manage a weakmap of next-stack-frame to > exception objects. Yes, that was exactly my first idea — to use a WeakMap from exceptions. Now it seems that copying part of the frame information will use less memory. But that's not certain :) > Of note is

Re: [PHP-DEV] Deferred backtrace generation algorithm.

Hello, Rob! > For what it is worth, the stack trace is not generated in the constructor (at > least from the perspective of the developer). This is a design feature. In PHP, call frames for PHP functions are stored in a separate stack. However, they are still stored following the stack (LIFO) pr

Re: [PHP-DEV] Deferred backtrace generation algorithm.

Hey Edmond, On 2.5.2025 10:14:37, Edmond Dantes wrote: Good day, everyone. In the neighboring thread Concept: Lightweight error channels, the topic of exception performance was discussed. The main issue is the immediate backtrace generation in the constructor, which can cause up to a 50% perfo

Re: [PHP-DEV] Deferred backtrace generation algorithm.

On Fri, May 2, 2025, at 10:14, Edmond Dantes wrote: > Good day, everyone. > > In the neighboring thread Concept: Lightweight error channels, the > topic of exception performance was discussed. > > The main issue is the immediate backtrace generation in the > constructor, which can cause up to a 5

Re: [PHP-DEV] Concept: Lightweight error channels

Hello. > Suppressing? You mean fataling. Suppressing implies ignore, which is the > exact opposite of what I am proposing. Yes, it seems I didn’t explain my thought clearly. We have the following code: ```php function some(): bool { return false; } function target(): void { if(some()

Re: [PHP-DEV] Concept: Lightweight error channels

Hi all, > On May 1, 2025, at 09:29, Levi Morrison wrote: > > On Tue, Apr 29, 2025 at 9:48 AM Paul M. Jones wrote: >> >> >> >>> On Apr 27, 2025, at 07:26, Niels Dossche wrote: >>> >>> Regarding performance however, rather than introducing yet another >>> completely new concept to do almost

Re: [PHP-DEV] Concept: Lightweight error channels

> > Do we consider a difference of 0.075/10s vs 0.115/10s that big a > > deal when compared to (e.g.) establishing a database connection? > > The first part, the 0.075 vs 0.115... yeah, we care. That's 50% > slower. But the thing is, the math with exceptions is kind of knowable > because o

Re: [PHP-DEV] Concept: Lightweight error channels

On Tue, Apr 29, 2025 at 9:48 AM Paul M. Jones wrote: > > > > > On Apr 27, 2025, at 07:26, Niels Dossche wrote: > > > > Regarding performance however, rather than introducing yet another > > completely new concept to do almost the same thing, why not try to improve > > exception performance inst

Re: [PHP-DEV] Concept: Lightweight error channels

On Thu, May 1, 2025, at 7:47 AM, Juris Evertovskis wrote: > On 2025-04-29 17:29, Matthew Weier O'Phinney wrote: > >> >> * Exceptions should not be used for normal application logic flow. If the >> "error" is recoverable and/or expected, use a different mechanism so you can >> use standard condi

Re: [PHP-DEV] Concept: Lightweight error channels

On Wed, Apr 30, 2025, at 9:18 PM, Morgan wrote: > On 2025-04-28 06:06, Larry Garfield wrote: >> Which is why I think we do want some kind of syntax similar to Rust's ?, so >> the above could be shortened back to this: >> >> function doStuff($id): string raises UserErr { >>$user = $repo->getUs

Re: [PHP-DEV] Concept: Lightweight error channels

On 2025-04-29 17:29, Matthew Weier O'Phinney wrote: * Exceptions should not be used for normal application logic flow. If the "error" is recoverable and/or expected, use a different mechanism so you can use standard conditional branching. As such, there are a lot of situations where I may not

Re: [PHP-DEV] Concept: Lightweight error channels

On 2025-04-28 06:06, Larry Garfield wrote: Which is why I think we do want some kind of syntax similar to Rust's ?, so the above could be shortened back to this: function doStuff($id): string raises UserErr { $user = $repo->getUser($id) reraise; // We have a good user. } One thing about

Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

On Wed, 30 Apr 2025 at 21:13, Larry Garfield wrote: > >> […] just that it's the only time I've seen $code used in the wild... > >> > > > > PDO (for better or worse) also uses the `$code` for the error code > > returned by the database. Unfortunately it also widens the (untyped) > > $code from int

Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

On Wed, Apr 30, 2025, at 1:06 PM, Tim Düsterhus wrote: > Hi > > On 4/30/25 15:33, Larry Garfield wrote: >> The only time I've seen anyone use $code is in TYPO3. Their coding >> standards say that any time you throw an exception, you use the current >> timestamp (determined manually) as a code.

Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

Hi On 4/30/25 13:18, Derick Rethans wrote: - Exceptions MUST NOT be ``final``. Could the RFC explain why not? I'm not sure if this is useful to add to the RFC itself as a “only extra explanation” and since the discussion is an equally official resource: The reason is to allow flexible exte

Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

Hi On 4/30/25 15:33, Larry Garfield wrote: The only time I've seen anyone use $code is in TYPO3. Their coding standards say that any time you throw an exception, you use the current timestamp (determined manually) as a code. That way there is a globally unique code regardless of exception t

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

Hi Máté and Tim Why can't the Url::resolve method also expose the `$errors` parameter like the constructor and the parse static method ? As far as I understand it nothing prevents the API from exposing the errors during URI resolution which is a proxy method for the constructor call just like the

Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

On Wed, Apr 30, 2025, at 6:18 AM, Derick Rethans wrote: > On Sun, 27 Apr 2025, Tim Düsterhus wrote: > - Any two exceptions with different causes MUST be identifiable either > by a unique exception class name, a stable ``$code``, or a > class-specific additional property suitable for programm

Re: [PHP-DEV] [RFC] [Discussion] Minor version compatibility

Am 27.04.2025 um 20:22 schrieb Gina P. Banyard : > I fundamentally reject the concept of this RFC to restrict our ability to do > input validation. I am sorry but I fail to see how the RFC restrict the ability to do input validation. > Emitting an E_DEPRECATED for invalid inputs remains utter n

Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

On Sun, 27 Apr 2025, Tim Düsterhus wrote: > Hi > > as announced in the URI RFC discussion thread > (https://externals.io/message/123997#127142), I've now written up an > “Exception Hierarchy” policy RFC together with Gina. > > Please find the following links: > > RFC: https://wiki.php.net/rfc/e

Re: [PHP-DEV] Re: RFC: Nested Classes

On 29 April 2025 19:50:52 BST, "Tim Düsterhus" wrote: >I'm saying that I cannot add a private class Foo\Bar inside of the class Foo >without checking whether a class Bar inside a namespace Foo already exists, >since both would conflict. Even more problematic: I can't add a class Bar >inside

Re: [PHP-DEV] Oniguruma maintenance was ended on 2025-04-24

2025年4月30日(水) 17:13 Anton Smirnov : > > On 30/04/2025 08:05, youkidearitai wrote: > > Hi, Internals > > > > Oniguruma(鬼車) maintenance was ended on April 24, 2025. > > https://github.com/kkos/oniguruma > > This library uses mbregex in php-src. > > > > There is forked library in Onigumo(鬼雲). > > http

Re: [PHP-DEV] Oniguruma maintenance was ended on 2025-04-24

On 30/04/2025 08:05, youkidearitai wrote: Hi, Internals Oniguruma(鬼車) maintenance was ended on April 24, 2025. https://github.com/kkos/oniguruma This library uses mbregex in php-src. There is forked library in Onigumo(鬼雲). https://github.com/k-takata/Onigmo How do we do that? - Move to Onigumo

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

Hi Máté and Tim I read the following in the RFC >Withers of Uri\WhatWg\Url follow the relevant “setter steps” that are defined by WHATWG URL. Unfortunately, these algorithms sometimes have surprising behavior where modification fails silently, and t

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

Hi Paul, I will try to address your concerns. Keep in mind that I am not the author of the RFC but I do like how it is currently shaped with some caveats but those can be put under future improvements. > So, one value added by splitting the classes is to resolve that asymmetry. First, I agree wi

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

Hi On 4/29/25 10:54, ignace nyamagana butera wrote: I have one last question while reviewing my polyfill implementation. Is it worth it adding a SensitiveParameter attribute on the argument of the following methods ? - Uri\Rfc3986\Uri::withUserInfo - Uri\WhatWg\Url::withPassword I'm fine with

Re: [PHP-DEV] Re: RFC: Nested Classes

Hi On 4/24/25 21:26, Rob Landers wrote: This was very deliberate after much feedback and careful design. People were quite clear (including yourself, if I recall) that they didn't want a new syntax. Since there is no new syntax, there is no way to tell (from the outside) whether A\B\C refers

Re: [PHP-DEV] Concept: Lightweight error channels

> On Apr 27, 2025, at 07:26, Niels Dossche wrote: > > Regarding performance however, rather than introducing yet another completely > new concept to do almost the same thing, why not try to improve exception > performance instead? > > I just opened a PR that makes instantiating exceptions m

Re: [PHP-DEV] Concept: Lightweight error channels

On Tue, Apr 29, 2025 at 9:09 AM Hammed Ajao wrote: > On Mon, Apr 28, 2025, 1:22 p.m. Larry Garfield > wrote: > >> On Mon, Apr 28, 2025, at 11:28 AM, Edmond Dantes wrote: >> >> I have already demonstrated how it can be solved without generics. >> Multiple response channels from a function alread

Re: [PHP-DEV] Concept: Lightweight error channels

On Mon, Apr 28, 2025, 1:22 p.m. Larry Garfield wrote: > On Mon, Apr 28, 2025, at 11:28 AM, Edmond Dantes wrote: > >> I have already demonstrated how it can be solved without generics. > Multiple response channels from a function already exist: Normal returns > and exceptions. Exceptions as curr

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

Hi Ignace & Maté and all, tl;dr: I argue against Ignace's objections to splitting the URI class into two classes (one that retains raw URI values and another that normalizes values as-it-goes). Jump to the very end for a discussion regarding the with() methods (search for the word "asymmetry" h

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

Hi Maté and Time, I have one last question while reviewing my polyfill implementation. Is it worth it adding a SensitiveParameter attribute on the argument of the following methods ? - Uri\Rfc3986\Uri::withUserInfo - Uri\WhatWg\Url::withPassword I'm fine with any answer ? Does it warrant a parag

Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

Hi On 4/29/25 00:36, Larry Garfield wrote: It's a common recommendation in userland, as it allows implementers to extend an existing exception (eg, InvalidArgumentException) of their choice while still being tagged as coming from a given library. Though I suppose if the policy doc also says

Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

On Mon, Apr 28, 2025, at 4:27 PM, Tim Düsterhus wrote: > Hi > > On 4/28/25 23:09, Larry Garfield wrote: * Would allowing an extension-tagging interface instead of a base class be an option? It still allows for catching "anything thrown by this extension", which I presume is the go

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

Hi Maté, > I fiddled a little bit with the implementation, and I went with the Uri\UriComparisonMode enum name at last. I hope that it is OK on your side. If no one objects with your name choice I am fine with it, as long as it is not a boolean :) I will adapt my polyfill. I think I have no more

Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

Hi On 4/28/25 23:09, Larry Garfield wrote: * Would allowing an extension-tagging interface instead of a base class be an option? It still allows for catching "anything thrown by this extension", which I presume is the goal. If not, why? See the “Choice of Base Exception” section in https:/

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

Hi Ignace, The $excludeFragment is `true` by default so in the example it should be > `false` instead. Perhaps using an Enum instead would make the > DX easier than using a boolean ? > I believe the same issue is in all examples regarding the use of that > parameter. > You are right, I completely

Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

On Mon, Apr 28, 2025, at 3:30 PM, Tim Düsterhus wrote: > Hi > > On 4/28/25 22:04, Larry Garfield wrote: >> Holy cow, thank you for this bit. The inability to tell what went wrong >> programmatically without string parsing the exception message is one of my >> biggest pet peeves in current except

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

Hi Paul, > The Rfc3986\Uri `raw()` methods present a departure from existing userland expectations when working with URIs. No existing URI package that I'm aware of retains the normalized values as their "main" values; the values are generally retained-as-given (i.e. "raw"). Nor do they afford get

Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

Hi On 4/28/25 22:04, Larry Garfield wrote: Holy cow, thank you for this bit. The inability to tell what went wrong programmatically without string parsing the exception message is one of my biggest pet peeves in current exceptions. Anything particular from the standard library? It might be

Re: [PHP-DEV] [RFC] Throwable Hierarchy Policy for Extensions

On Sun, Apr 27, 2025, at 4:45 PM, Tim Düsterhus wrote: > Hi > > On 4/27/25 23:16, Kamil Tekiela wrote: >> The exception message MUST NOT be the only means of distinguishing >> exceptions. Any two exceptions with different messages MUST be >> identifiable either by a unique exception class name or c

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

Hi Maté and all, > On Apr 27, 2025, at 16:47, Máté Kocsis wrote: > > Hi Tim, ... >> So it seems to be safer to use the naming without the `raw` and then in >> the documentation explain what happens with useful examples, just like >> the RFC already does. > > We discussed this off the list, an

Re: [PHP-DEV] Concept: Lightweight error channels

On Mon, Apr 28, 2025, at 11:28 AM, Edmond Dantes wrote: >> I have already demonstrated how it can be solved without generics. >> Multiple response channels from a function already exist: Normal returns and >> exceptions. Exceptions as currently designed are just very poorly suited to >> the p

Re: [PHP-DEV] Concept: Lightweight error channels

> I have already demonstrated how it can be solved without generics. Multiple response channels from a function already exist: Normal returns and exceptions. Exceptions as currently designed are just very poorly suited to the problem space I am describing. If another error channel is introduced,

Re: [PHP-DEV] Concept: Lightweight error channels

On Mon, Apr 28, 2025, at 6:46 AM, Edmond Dantes wrote: > Later in the letter you explain in more detail that this is *not a > special kind of exception*, nor a new execution flow, but rather a* > special type of result*. > > But if this is a special type of result, then it should follow *the

Re: [PHP-DEV] Concept: Lightweight error channels

> > > 3) Implement a new LightException (or similar name) with no args in > getTrace(). > > + or 4) Deferred backtrace mechanism: > > 1. Does not compute the backtrace when the exception is created. > 2. The backtrace is fully computed only if the exception is caught using a > catch block or by a

Re: [PHP-DEV] Concept: Lightweight error channels

> 3) Implement a new LightException (or similar name) with no args in getTrace(). + or 4) Deferred backtrace mechanism: 1. Does not compute the backtrace when the exception is created. 2. The backtrace is fully computed only if the exception is caught using a catch block or by a global handler w

Re: [PHP-DEV] Concept: Lightweight error channels

> Edmond Dantes hat am 28.04.2025 13:46 CEST geschrieben: > > > Hello all. > > > Yes. And even if it can be made faster (as it looks like Niels is doing, > > which is great), it will never be as fast as an empty constructor and a > > return. That's the level I'm proposing. > > If th

Re: [PHP-DEV] Concept: Lightweight error channels

Hello all. > Yes. And even if it can be made faster (as it looks like Niels is doing, which is great), it will never be as fast as an empty constructor and a return. That's the level I'm proposing. If the backtrace is generated only when needed, rather than at the moment the exception is create

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

On Mon, Apr 28, 2025 at 9:05 AM ignace nyamagana butera wrote: > Hi Maté, > > I found another typo in the RFC examples due to the use of boolean as > parameters > > // The fragment component of Uri\WhatWg\Url can also be taken into > account$url = new Uri\WhatWg\Url("https://example.com#foo";);$

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

Hi Maté, I found another typo in the RFC examples due to the use of boolean as parameters // The fragment component of Uri\WhatWg\Url can also be taken into account$url = new Uri\WhatWg\Url("https://example.com#foo";);$url->equals(new Uri\WhatWg\Url("https://example.com";), true); // false The $

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

Hi On 4/27/25 23:47, Máté Kocsis wrote: […] Thank you. I have just given the RFC another full read (the 2025/04/27 21:44 version) and I do not have any further remarks. I'm happy with everything that is said in the RFC and I'm really looking forward to vote “Yes” :-) Best regards Tim Düst

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

Hi Tim, > In https://news-web.php.net/php.internals/127114 I suggest to only > provide the "non-raw" methods, so I believe you misread that. I've just > given the RFC another read and thought about the naming and I believe I > still prefer not having the "raw" in the name: > > - Having the `raw`

  1   2   3   4   5   6   7   8   9   10   >