On 25/02/2025 13:36, Paul M.Jones wrote:
Hi there,
On Feb 24, 2025, at 03:36, Tim Düsterhus <t...@bastelstu.be> wrote:
...
but had a look at the “after-action summary” thread and specifically Côme’s
response, which you apparently agreed with:
My take on that is more that functionality in core needs to be «perfect», or at
least near unanimous.
Côme Chilliet's full quote goes on to say "And of course it’s way easier to find a
solution which pleases everyone when it’s for something quite simple" -- the example
was of `str_contains()`.
Or perhaps phrased differently, like I did just a few days ago in:
https://externals.io/message/126350#126355
The type of functionality that is nowadays added to PHP’s standard library is
“building block” functionality: Functions that a userland developer would
commonly need in their custom library or application.
*Correctly* processing URIs is a common need for developers and it’s
complicated to do right, thus it qualifies as a “building block”.
Agreed. Add to that:
On Feb 23, 2025, at 18:48, Gina P. Banyard <intern...@gpb.moe> wrote:
Considering that one of the other stated goals of this RFC is to provide this
API to other core extensions, the previous objections do not apply here.
(The previous objections being that this ought to be left in userland.)
* * *
I'm repeatedly on record as saying that PHP, as a web-centric language, ought
to have more web-centric objects available in core. A _Request_ would be one of
those; a _Response_ another; and as being discussed here, a _Url_.
However, if it is true that ...
- "it’s way easier to find a solution which pleases everyone when it’s for something
quite simple"
- "The type of functionality that is nowadays added to PHP’s standard library is
“building block” functionality: Functions that a userland developer would commonly need
in their custom library or application."
- "one of the other stated goals of this RFC is to provide this API to other core
extensions"
- "Parsing is the single most important operation to use with URIs where a URI
string is decomposed into multiple components during the process." (from the RFC)
... then an extensive set of objects and exceptions is not strictly necessary.
Something like `function parse_url_whatwg(string $url_string, ?string $base_url
= null) : array`, with an array of returned components, would meet all of those
needs.
Similarly, something like a `function parse_url_rfc3986(string $uri_string,
?string $base_url = null) : array` does the same for RFC 3986 parsing.
Those things combined provide solid parsing functionality to userland, and make
that parsing functionality available to other core extensions.
-- pmj
Hi Paul,
The problem with your suggestion is that the specification from WHATWG
and RFC3986/3987 are so different and that the function you are
proposing won't be able to cover the outcome correctly (ie give the
developper all the needed information). This is why, for instance, Maté
added the getRaw* method alongside the normalized getter (method without
the Raw prefix).
Also keep in mind that URL construction may also differ between
specifications so instead of just 2 functions you may end up woth 4
methods not counting error jandling. So indeed using an OOP approach
while more complex is IMHO the better approach.
