Re: [RFC] [Discussion] Followup Improvements for ext/uri

Hi On 3/13/26 10:38, Máté Kocsis wrote:

Personally - and I may be in the minority - I don't see an issue with having two static methods on Uri/Url.

As I had previously mentioned in private, I also (very strongly) believe that making these static methods on the URI class is not the correct design. Classes are not intended to be “pseudo-namespaces” and any (public) functionality on a class should directly relate to it, otherwise you're just polluting the API surface, which makes autocompletion and discoverability worse and documentation more complex. In practice this means that public static methods should be limited to “named constructors”.

Uri::percentEncode() and Uri::percentDecode() as well as Url::percentEncode() and Url::percentDecode() could indeed be implemented via a dedicated UriPercentEncoder and UrlPercentEncoder class, or even a shared PercentEncoder one, but: - Its methods would still be static - I don't think it's worth to add one or two dedicated classes just for this purpose

I agree here: A dedicated class with static methods would still be a pseudo-namespace. It would be …

I also got feedback that these functions could be free-standing in the URI namespace. But I really don't like free standing functions,

… equivalent to free-standing functions but worse. Personal preference should not play a role here: PHP supports namespacing functions and within PHP's standard library we should embrace this capability. A big benefit of free-standing functions is that they would be easy to polyfill, particularly when we need additional of them in future PHP versions.

So all in all... As far as I can see, not even a Uri\Rfc3986\UriComponent enum could provide a complete solution for the custom percent-encoding/decoding part of the proposal. If we used a Uri\Rfc3986\UriEncoding enum name instead, then there would be no issue with the various kinds of encoding/decoding modes not referring to URI components, but the naming would probably still not be right, as I wouldn't expect a class name with "ing" suffix to perform percent-encoding/decoding itself. But I'm happy to be corrected by native English speakers :)

enum Uri\Rfc3986\PercentEncoder enum Uri\WhatWg\PercentEncoder with *non*-static encode() and decode() methods would work for me. I don't have a strong preference between “instance methods on an enum” and “free-standing functions”, but I have a strong preference against “static methods”. Best regards Tim Düsterhus