Re: [RFC] [Under Discussion] New Curl URL API

On Fri, 24 Jun 2022 at 15:05, Jeffrey Dafoe <JDafoe@fsx.com> wrote: > A thin wrapper would be the most flexible. Someone can always write a > "friendlier" class using your thin wrapper, as you mentioned, but one > cannot easily go the other direction. > I think this argument has some validity when talking about the entire API of a library like curl. But we're not, we're talking about a tiny bounded context. The underlying implementation consists of 6 functions, 4 of which are trivial: * An argument-less "constructor" https://curl.se/libcurl/c/curl_url.html * An equivalent to PHP "clone" https://curl.se/libcurl/c/curl_url_dup.html * A cleanup method, which would be automatic in any PHP implementation https://curl.se/libcurl/c/curl_url_cleanup.html * A function for looking up error strings from codes https://curl.se/libcurl/c/curl_url_strerror.html That leaves the main getter and setter functions https://curl.se/libcurl/c/curl_url_get.html and https://curl.se/libcurl/c/curl_url_set.html which take the same arguments: * A resource handle * The URL part to handle * The new value for set, or an output parameter for get * A set of flags If we really believe the goal is to expose the C API in PHP, the get function would look like this: /** * @return int Error code */ function curl_url_get(resource $url, int $what, string &$part, int $flags): int That would be ... awful, and I hope nobody's really suggesting that. So we have to map each part to some concept in PHP, which is what the proposal does: * The resource handle becomes $this * The $what argument becomes the method name * The output parameter becomes the return value * The error code becomes an exception There's no "flexibility" which has been lost, and no "future changes" which are being prevented. The only other change is a few renamed constants, which I suggested on the PR. I can see an argument for making them match the library exactly; but it's the *values* that actually matter, so I don't see why we shouldn't choose our own names if they're descriptive of the functionality. Regards, -- Rowan Tommins [IMSoP]