On 17/03/2025 20:58, Máté Kocsis wrote:
Hi Ignace,
1) around `Uri\UninitializedUriException` If I look at the
behaviour of
`DatetimeImmutable` in the same scenario or a Userland object
instead of
throwing an exception an error is thrown
see:
- https://3v4l.org/d4VrY
- https://3v4l.org/Wn7En
Shouldn't the URI feature follow the same path for consistency ?
Instead
of throwing an exception it should throw an Error on uninitialized
issue
at least.
Yes, you are right! Uri\UninitializedUriException should extend an
Error indeed,
since people shouldn't try to catch it either.
2) around Normalization. In case of query normalization, sorting the
query string is not mention does it means that with the current
feature
`http://example.com?foo=bar&foo=rab`
<http://example.com?foo=bar&foo=rab>
is different from
`http://example.com?foo=rab&foo=bar`
<http://example.com?foo=rab&foo=bar>
Yes, that's the case, this feature is not implemented. As far as I see
though, it's better
not to change the order of query parameters, especially the order of
duplicated
parameters in order not to accidentally change the intended meaning of
the query string.
What's your stance here?
Máté
Hi Maté,
Thanks for the clarifications, I ask for the latter because I am trying
to create a polyfill using league/uri-interfaces so
my questions come essentially from me trying to create the correct
polyfill to better understand the new class (specifically,
the RFC3986 Uri). You can find the ongoing work here if you want to see
https://github.com/bakame-php/aide-uri/blob/main/src/Uri.php
While implementing the polyfill I am finding easier DX wise to make the
constructor private and use instead named constructors for
instantiation. I would be in favor of
`Uri::parse` and `Uri::tryParse` like it is done currently with Enum and
the `from` and `tryfrom` named constructors.
My reasoning is as follow:
there's no right way or wrong way to instantiate an URI there are only
contexts. While the parse method is all about parsing a string, one
could legitimately use other named constructors like
`Uri::fromComponents` which would take for instance the result of
parse_url to build a new URI. This can become handy in the case of
RFC3986 URI if you need to create an new URI not related to the http
scheme and that do not use all the components like the email, data or
FTP schemes.
By allowing creating URI based on their respective components value
you make it easier for dev to use the class. Also this means that if we
want to have a balance API then a `toComponents` method should come hand
in hand with the named constructor.
I would understand if that idea to add both components related methods
is rejected, they could be implemented on userland, but the main point
was to prove that from the VO or the developer POV in absence of a
clearly defined instantiation process, having a traditional constructor
fails to convey all the different way to create an URI.
