Re: [RFC] [Discussion] Followup Improvements for ext/uri
| From: | Máté Kocsis | Date: | Sat, 06 Dec 2025 11:53:34 +0000 |
| Subject: | Re: [RFC] [Discussion] Followup Improvements for ext/uri | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-129567@lists.php.net to get a copy of this message | ||
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 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?
>
>
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áté
>