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

From: 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é >

« previous php.internals (#129567) next »