Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130627
Message-ID: <1fee2f46-27b7-4eb2-908f-b38f8c78d8c9@bastelstu.be>
Date: Tue, 14 Apr 2026 00:27:28 +0200
Precedence: list
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] [Discussion] Followup Improvements for ext/uri
To: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>,
 ignace nyamagana butera <nyamsprod@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
References: <CAH5C8xXUPKgd0wWwLC3G2Ye=kRZN58gK3DY82v5GoduBNNtb5A@mail.gmail.com>
 <CAOV5rgZ1LTVf9PBpfQekahmESo=KXE=RVrpeUXrbqxG4OSDMnQ@mail.gmail.com>
 <d6a46bb627a9545e621f37e83c0441e5@glaive.pro>
 <CAOV5rgZGKJEo+jV7q-qQFB59CXhfNwadYPDbm70e_F+1v=Fgng@mail.gmail.com>
 <CAH5C8xWwcNC3z=FxQZiN2r1aZ1FgriVNAtdw+YwhaN4S2joyzw@mail.gmail.com>
 <CAOV5rgaLX9s-=WZZgxoTE4wmWEzL9mZUF-d8bzGrN3BQDU7i3w@mail.gmail.com>
 <CAOV5rgY3+PrOk2sH0iZ2ne1wg1WVzW4evh6qwu1nyq68tMH-9A@mail.gmail.com>
 <CAH5C8xUEBtywOxgV4zgHVhdzO0KoFejtp04q0LQ+bEAb9nUAvw@mail.gmail.com>
 <CAOV5rgaGjJ+_Qa10pVaCYD_aozV10+UHvLUuVuNOXTz87xHpXA@mail.gmail.com>
 <CAOV5rgZ5y6YF3hLeDAc8TcaOyxkbbF7S0U7R7JMx8Cwff=3QGA@mail.gmail.com>
 <CAH5C8xXAtUN0ja_thZqbN4u4nndr2Lp_SxqZT3E+WN5ASFqWSA@mail.gmail.com>
 <CAH5C8xVjx1v_CX+5O4sj7CVyJOx4rDASvuqOukWfgupPa=YtGA@mail.gmail.com>
 <CAOV5rgbsDscEffqiv+c7WThN-Aj0xhL0w5eE13ALY_F5Kmcwmg@mail.gmail.com>
 <CAH5C8xXXrY5iPuAcL0XXYDoRPh=Tz0m7xhszspNqXnfVmM_aAQ@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAH5C8xXXrY5iPuAcL0XXYDoRPh=Tz0m7xhszspNqXnfVmM_aAQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

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