Alternative Proposal for Segment handling #174
Draft
+184
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@kocsismate, @TimWolla since it would mean another wall of text I choose to create this POC instead. in response to https://news-web.php.net/php.internals/129595
TL;DR:
The UriPathSegments has 2 properties:
UriPathType (absolute or relatives) and the segments.
Unless I am mistaking or forgetting something both URL and URI encode and decode path the same way. So in this case having 2 class is meaningless.
Segments could be accessed and manipulated decoded (which makes for improved DX) and the path is reconstructed safely using both properties (we stay away from how C# does its representation).
The class could be improved with more methods but for now I added
toRawStringtoString(here the remove dot segments algorithm is used)Of note in the case of the Url class there can not be any difference between both string representation but it can for the path coming from an RFC3986 URI class.
IMHO this version improve DX and avoid adding with* and get* methods on the URI/Url class because not all Url/Uri uses segments a good example being the URI/Url with the data scheme.