Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129501
Precedence: list
MIME-Version: 1.0
References: <CAH5C8xXUPKgd0wWwLC3G2Ye=kRZN58gK3DY82v5GoduBNNtb5A@mail.gmail.com>
In-Reply-To: <CAH5C8xXUPKgd0wWwLC3G2Ye=kRZN58gK3DY82v5GoduBNNtb5A@mail.gmail.com>
Date: Tue, 2 Dec 2025 07:49:05 +0100
Message-ID: <CAOV5rgb1pAPQ7ZSavYRdS7QJne9ZaeE1Q-7OX7pgF-k=h0i9=g@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Followup Improvements for ext/uri
To: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a6f4650644f27ecd"
From: nyamsprod@gmail.com (ignace nyamagana butera)

--000000000000a6f4650644f27ecd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi M=C3=A1t=C3=A9,
After quickly checking the proposed API for Percent-Encoding and Decoding
Support I wonder if the following would not
be more appropriate ?

```php
namespace Uri\Rfc3986 {
    enum UriPercentEncoding
    {
        case UserInfo;
        case Host;
        case RelativeReferencePath;
        case RelativeReferenceFirstPathSegment;
        case Path;
        case PathSegment;
        case Query;
        case FormQuery;
        case Fragment;
        case AllReservedCharacters;
        case All;

        public function encode(string $input): string {}
        public function decode(string $input): string {}
    }
}
```

With the same logic being applied in the `Uri\Whatwg` namespace. This
would make for a better encapsulated feature. So we can

have a clear distinction between the Value Object, its builder and the
Encoding mechanism ? What do you think?

Best regards,

Ignace


On Mon, Dec 1, 2025 at 9:53=E2=80=AFPM M=C3=A1t=C3=A9 Kocsis <kocsismate90@=
gmail.com> wrote:

> Hi Everyone,
>
> I'd like to introduce my latest RFC that I've been working on for a while
> now: https://wiki.php.net/rfc/uri_followup.
>
> It proposes 5 followup improvements for ext/uri in the following areas:
> - URI Building
> - Query Parameter Manipulation
> - Accessing Path Segments as an Array
> - Host Type Detection
> - URI Type Detection
> - Percent-Encoding and Decoding Support
>
> I did my best to write an RFC that was at least as extensive as
> https://wiki.php.net/rfc/url_parsing_api had become by the end. Despite
> my efforts,
> there are still a couple things which need a final decision, or which
> need to be polished/improved. Some examples:
>
> - How to support array/object values for constructing query strings? (
> https://wiki.php.net/rfc/uri_followup#type_support)
> - How to make the UriQueryParams and UrlQueryParams classes more
> interoperable with the query string component (mainly with respect to
> percent-encoding)? (
> https://wiki.php.net/rfc/uri_followup#percent-encoding_and_decoding)
> - Exactly how the advanced percent-decoding capabilities should work? Doe=
s
> it make sense to support all the possible modes (UriPercentEncodingMode)
> for percent-decoding as well (
> https://wiki.php.net/rfc/uri_followup#percent-encoding_and_decoding_suppo=
rt
> )
> - etc.
>
> Regards,
> M=C3=A1t=C3=A9
>

--000000000000a6f4650644f27ecd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi M=C3=A1t=C3=A9,<div>After quickly checking the proposed=
 API for Percent-Encoding and Decoding Support I wonder if the following wo=
uld not=C2=A0</div><div>be more appropriate ?</div><div><div style=3D"color=
:rgb(8,8,8)"><pre style=3D"font-family:&quot;JetBrains Mono&quot;,monospace=
">```php<br>namespace Uri\Rfc3986 {<br>=C2=A0 =C2=A0 enum UriPercentEncodin=
g<br>=C2=A0 =C2=A0 {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 case UserInfo;<br>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 case Host;<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 case Rel=
ativeReferencePath;<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 case RelativeReferenceFi=
rstPathSegment;<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 case Path;<br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 case PathSegment;<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 case Query;<=
br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 case FormQuery;<br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 case Fragment;<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 case AllReservedCharacter=
s;<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 case All;<br><br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 public function encode(string $input): string {}<br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 public function decode(string $input): string {}<br>=C2=A0 =C2=
=A0 }<br>}<br>```</pre><pre style=3D""><font face=3D"arial, sans-serif">Wit=
h the same logic being applied in the `Uri\Whatwg` namespace. This would ma=
ke for a better encapsulated feature. So we can</font></pre><pre style=3D""=
><font face=3D"arial, sans-serif">have a clear distinction between the Valu=
e Object, its builder and the Encoding mechanism ? What do you think?</font=
></pre><pre style=3D""><font face=3D"arial, sans-serif">Best regards,</font=
></pre><pre style=3D""><font face=3D"arial, sans-serif">Ignace</font></pre>=
</div></div></div><br><div class=3D"gmail_quote gmail_quote_container"><div=
 dir=3D"ltr" class=3D"gmail_attr">On Mon, Dec 1, 2025 at 9:53=E2=80=AFPM M=
=C3=A1t=C3=A9 Kocsis &lt;<a href=3D"mailto:kocsismate90@gmail.com">kocsisma=
te90@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"ltr">Hi Everyone,<div><br></div><div>I&#39;d like=
 to introduce my latest RFC that I&#39;ve been working on for a while now: =
<a href=3D"https://wiki.php.net/rfc/uri_followup" target=3D"_blank">https:/=
/wiki.php.net/rfc/uri_followup</a>.</div><div><br></div><div>It proposes 5=
=C2=A0followup=C2=A0improvements for ext/uri in the following areas:</div><=
div>- URI Building<br>- Query Parameter Manipulation<br>- Accessing Path Se=
gments as an Array<br>- Host Type Detection<br>- URI Type Detection<br>- Pe=
rcent-Encoding and Decoding Support</div><div><br></div><div>I did my best =
to write an RFC that was at least as extensive as=C2=A0<a href=3D"https://w=
iki.php.net/rfc/url_parsing_api" target=3D"_blank">https://wiki.php.net/rfc=
/url_parsing_api</a> had become by the end. Despite my efforts,</div><div>t=
here are still a couple things which need=C2=A0a final decision, or which n=
eed=C2=A0to be polished/improved. Some examples:</div><div><br></div><div>-=
 How to support array/object values for constructing query strings? (<a hre=
f=3D"https://wiki.php.net/rfc/uri_followup#type_support" target=3D"_blank">=
https://wiki.php.net/rfc/uri_followup#type_support</a>)</div><div>- How to =
make the UriQueryParams and=C2=A0UrlQueryParams classes more interoperable =
with the query string component (mainly with respect to percent-encoding)? =
(<a href=3D"https://wiki.php.net/rfc/uri_followup#percent-encoding_and_deco=
ding" target=3D"_blank">https://wiki.php.net/rfc/uri_followup#percent-encod=
ing_and_decoding</a>)</div><div>- Exactly how the advanced percent-decoding=
 capabilities should work? Does it make sense to support all the possible m=
odes (UriPercentEncodingMode) for percent-decoding as well (<a href=3D"http=
s://wiki.php.net/rfc/uri_followup#percent-encoding_and_decoding_support" ta=
rget=3D"_blank">https://wiki.php.net/rfc/uri_followup#percent-encoding_and_=
decoding_support</a>)</div><div>- etc.</div><div><br></div><div>Regards,</d=
iv><div>M=C3=A1t=C3=A9</div></div>
</blockquote></div>

--000000000000a6f4650644f27ecd--