Send a blank email to [email protected] to get a copy of this message
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.