On 23 June 2022 17:48:57 BST, Levi Morrison via internals <internals@lists.php.net> wrote: >IMO, this should mirror the low-level curl url API very directly. The >basis of my opinion is that we do not own libcurl; we are merely >adapting it for use in PHP. We cannot anticipate changes in their >design, nor do we have authority to do so if we feel something should >change. Touching it as little as possible makes it easier to track >upstream changes, etc. > >Based on that, I think the naming should be closer to libcurl.: > - CurlUrl::URL_ENCODE should be CurlUrl::URLENCODE > - CurlUrl::URL_DECODE should be CurlUrl::URLDECODE > >And so on, only differing if necessary because something is a reserved >word. The API should be as exact as possible to what libcurl provides. >The "helpers" getHost, getPassword, etc should be removed and should >expose `curl_url_get` more directly. > >Of course, it should be object based instead of resource based, but that's it. > >A nicer API can be built on top of it, but I don't think that's the >role this particular API should play.
For the record, I disagree with literally everything you've said here. PHP indeed does not own libcurl, and nor does libcurl own PHP. We are targeting a different audience, and have a different set of facilities available to us. We have our own documentation, so there is no reason a user of PHP should know or care what the underlying implementation looks like, any more than they should know how the memory allocation works. If the underlying library adds a feature, it will be as easy to add a new method as a new constant. If the underlying library changes behaviour, we will want to make our own decision on whether that meets our compatibility policy, and whether to emulate the older behaviour (or indeed emulate the newer behaviour on systems with an older library). Twenty years ago, maybe PHP programmers were used to it being a veneer over C. I don't think that is or should be the expectation today, unless you're using FFI. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
