Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129567
Precedence: list
MIME-Version: 1.0
References: <CAH5C8xXUPKgd0wWwLC3G2Ye=kRZN58gK3DY82v5GoduBNNtb5A@mail.gmail.com>
 <CAOV5rgb1pAPQ7ZSavYRdS7QJne9ZaeE1Q-7OX7pgF-k=h0i9=g@mail.gmail.com>
In-Reply-To: <CAOV5rgb1pAPQ7ZSavYRdS7QJne9ZaeE1Q-7OX7pgF-k=h0i9=g@mail.gmail.com>
Date: Sat, 6 Dec 2025 12:53:34 +0100
Message-ID: <CAH5C8xXDeTYME3tTa6MhXNhAsq=Pa82DYXTK5dqPG0=5zcvRvw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Followup Improvements for ext/uri
To: ignace nyamagana butera <nyamsprod@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d980d40645473654"
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--000000000000d980d40645473654
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Ignace,

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 wou=
ld make for a better encapsulated feature. So we can
>
> have a clear distinction between the Value Object, its builder and the En=
coding mechanism ? What do you think?
>
>
Yes, I was also wondering whether the URI/URL classes are really the best
places for the percentEncode() and percentDecode() methods, because
they are not only relevant for URIs/URLs but e.g. also for QueryParams.. So
overall, I'm also fine with moving the percent-encoding/decoding
capabilities to a separate place. Honestly, the enums themselves didn't
come to my mind... I think it's a good candidate. So I'll definitely
consider it.

Probably my only concern is the name, specifically, the "ing" suffix: it
suggests that it can only keep data, and cannot do any operation. The
latter would
rather have an "er" suffix (e.g. `UriPercentEncoder`). But I'm happy to get
feedback/suggestions about the options.

M=C3=A1t=C3=A9

>

--000000000000d980d40645473654
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Ignace,<div><br></div></div><div class=
=3D"gmail_quote gmail_quote_container"><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"><div>After quickly checking the proposed API=
 for Percent-Encoding and Decoding Support I wonder if the following would =
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 UriPercentEncoding<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 Relativ=
eReferencePath;<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 case RelativeReferenceFirstP=
athSegment;<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 AllReservedCharacters;<b=
r>=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><font face=3D"arial, sans-serif">With the same logic =
being applied in the `Uri\Whatwg` namespace. This would make for a better e=
ncapsulated feature. So we can</font></pre><pre><font face=3D"arial, sans-s=
erif">have a clear distinction between the Value Object, its builder and th=
e Encoding mechanism ? What do you think?</font></pre></div></div></div></b=
lockquote><div><br></div><div>Yes, I was also wondering whether the URI/URL=
 classes are really the best places for the percentEncode() and percentDeco=
de() methods, because</div><div>they are not only relevant for URIs/URLs bu=
t e.g. also for QueryParams.. So overall, I&#39;m also fine with moving the=
 percent-encoding/decoding</div><div>capabilities to a separate place. Hone=
stly, the enums themselves=C2=A0didn&#39;t come to=C2=A0my=C2=A0mind... I t=
hink it&#39;s a good candidate. So I&#39;ll definitely consider it.</div><d=
iv><br></div><div>Probably my only concern is the name, specifically, the &=
quot;ing&quot; suffix: it suggests that it can only keep data, and cannot d=
o any operation. The latter would</div><div>rather have an &quot;er&quot; s=
uffix (e.g. `UriPercentEncoder`). But I&#39;m happy to get feedback/suggest=
ions about the options.</div><div><br></div><div>M=C3=A1t=C3=A9</div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div>
</blockquote></div></div>

--000000000000d980d40645473654--