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

As far as I am concerned, this brings me back to my earlier suggestion (with a Polyfill implementation). The name can be changed or improved but I did go with an Enum and two public methods encode/decode see https://github.com/thephpleague/uri-src/pull/186 which to me sounded like: - a better DX. which avoid polluting the Uri(l) classes - allow for an easier transition with an additional polyfill - properly decouple the Encoding feature from the URI parsing ones. so am I +1 on this change that I have already expressed which is my biggest concern over the current RFC proposal On Wed, Apr 15, 2026 at 10:23 PM Tim Düsterhus <tim@bastelstu.be> wrote: > Hi > > Am 2026-04-15 22:04, schrieb Larry Garfield: > > For host type detection, what does a null return signify? UrlHostType > > includes an Empty case, which I'd assume would be used in that > > situation. And I'd rather have an Empty case on UriHostType as well > > rather than null, unless someone can make a good argument for using > > null instead... > > An empty host is semantically different from a missing host. > > You can check that with the existing functionality in PHP 8.5, where > getHost() is ?string for both > RFC 3986 and WHATWG URL in accordance > with the respective standards. If getHostType() will return > null if > getHost() returns null. The > cases of the Ur[il]HostType enums in the > featured RFC are also pulled straight from the respective > specifications. > > > LeadingSlashPolicy::AddForNonEmtpyRelative is... a mouthful. > > Self-documenting is fine, but as the example demonstrates it quickly > > creates super long lines. That could be a problem in, say, a match() > > statement, inside a method, where with that enum value as a case you'd > > be more than halfway across the screen before you get to the executable > > code for that case. Is there no way to make that whole thing shorter? > > FYI: I've also had little time for this RFC, but I've started discussing > spinning off the “path segment” part of the RFC into a dedicated RFC > with Mate off-list a few days ago, similarly to how the query parameters > part has been spun off because it has become too complicated for a bulk > RFC. > > > I'm not sure how I feel about object methods on the enum. That would > > be something like: > > > > use Uri\Rfc3986\PercentEncoder; > > > > PercentEncoder::Path->encode($someval); > > > > Right? […] > > Yes. > > > use Uri\Rfc3986\encode; > > > > encode($someval, PercentEncoder::Path); > > > > Is about the same length, and with PFA easily pre-configurable, and > > closer to what is typically seen in the wild today. > > FWIW: The enum would also be “pre-configurable” with > https://wiki.php.net/rfc/partial_function_application_this. > Arnaud and I > are working on a more general version of that RFC based on Bob's > feedback, but will need to figure out the latest edge cases before > proposing it. > > Best regards > Tim Düsterhus >