Hi Pierrick,
On Thu, 16 Jun 2022 at 22:44, Pierrick Charron <pierr...@php.net> wrote: > Is it OK to have one part > that is a thin wrapper and another part that is a "remodeling" of the API ? > (This is not a rhetorical question, I really ask myself the question). > I agree with others that the new API should be exposed via a new, well-designed object, with no procedural version or low-level equivalence to libcurl. Something that nobody's brought up yet is that the curl extension actually already has a facility designed this way: CurlFile and CurlStringFile are high-level PHP objects which allow users to interact with file uploads, without any knowledge of what libcurl's API for them looks like. I think it's perfectly reasonable for CurlUrl to be designed the same way, regardless of what else we do with the extension. > We could also keep the existing API as is and not improve it living only > with the procedural API, but I think that with minimal effort, we could get > some small (but still) benefits. Yes, CurlHandle for example would just be > a wrapper on the procedural API that happens to use `->` and throw > exceptions instead of returning null/false, but one of the gains would be > to help developers with autocomplete to find methods they can call on the > handle. > This feels like a very small gain, since users can already type "curl_" and get a list of all curl functions. It also has real costs: users may be confused why there are two ways of writing the same thing; and it sets the precedent that methods on CurlHandle should mirror curl_* functions, even though we know those have terrible usability. I think if we do add methods to the CurlHandle class, they should be higher-level methods for common tasks that are currently unnecessarily awkward. I don't think we'd need to add everything at once, just establish some general design principles. (I'm honestly surprised that CURLOPT_RETURNTRANSFER, and curl_setopt in general, doesn't make it onto more lists of the worst parts of PHP.) Regards, -- Rowan Tommins [IMSoP]