Hi Maté,
I finally got the time to review the proposed API and I did some experiments
using a PHP userland polyfill for RFC3986Uri to test the water and to see if I
did understood everything.
First thing first, the API is really well thought and at least for me and my
League/Uri package it is really easy to
go around and use it if needed. Having said that I had some questions during
implementation.
Specifically for RFC3986Uri I see that the only difference between the `parse`
named constructor and the constructor is that the former will return `null`
instead of throwing an exception. But it is not clear if both methods can work
with partial URI. What is the expected result of
new Rfc3986Uri('?query#fragment');
will the class throw an exception because the missing base URI or will the
parsing still occur and return a new instance of the URI ? Whatever the answer
I think it should be clearly stated in the RFC. Because from the look of it
One may think that partial parsing which is use a lot is not longer supported
and possible and that the URI should always be absolute. If partial parsing is
in fact no longer supported maybe a distinct method should be added to support
for that scenario. AFAIK, the WHATWGUri does not support partial URI and always
required an absolute URI. So maybe adding a distinct named constructor
specifically for the RFC3986 would make understanding the code easier and
reduce suprises on usage ?
I also think that the RFC should emphasized that the RFC3986 URI is only
**parsing** the URI and not validating the URI like the WHATWGUri counterpart.
the following URI will pass without issue
new Rfc3986('https:example.com');
this is a valid RFC3986 URI but it is clearly not a valid http URL.
