Newsgroups: php.internals,php.internals Path: news.php.net Xref: news.php.net php.internals:126500 php.internals:126501 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: by qa.php.net (Postfix, from userid 65534) id 4461E1A00BD; Tue, 25 Feb 2025 15:55:21 +0000 (UTC) To: internals@lists.php.net, "Paul M.Jones" , =?UTF-8?Q?Tim_D=C3=BCsterhus?=@php.net Message-ID: Date: Tue, 25 Feb 2025 16:55:20 +0100 Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: nyamsprod@gmail.com Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API , "Gina P. Banyard" Cc: PHP Internals List References: <811B65CE-1DF0-4A47-937C-4FCB6E945B92@pmjones.io> <19377F60-FB7F-4E6E-A085-4DCB6CD92234@pmjones.io> Content-Language: fr In-Reply-To: <19377F60-FB7F-4E6E-A085-4DCB6CD92234@pmjones.io> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Posted-By: 94.225.114.231 From: nyamsprod@gmail.com (ignace nyamagana butera) On 25/02/2025 13:36, Paul M.Jones wrote: > Hi there, > >> On Feb 24, 2025, at 03:36, Tim Düsterhus 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 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.