Re: Re: [RFC] OOP API for cURL extension

On 17 February 2024 15:57:20 GMT, Larry Garfield <larry@garfieldtech.com> wrote: >The RFC would also benefit greatly from some practical examples of using the new API. Right now >it's not clear to me (as someone who almost never uses Curl directly) how/why I'd use any >of these, since there's still "a whole crapton of int constants I don't understand >floating around." The suggestion to use an Enum (or several) here is a good one and would help >a lot with that, so I'm +1 there. To my mind, the *eventual* aim should be that users don't *need* a userland wrapper just to make a simple request in a readable way, and that setting raw curl options becomes an advanced feature that most users never need. I know a lot of people's minds will immediately go to request and response objects, but I think we can go a long way by just making well-named methods wrapping one or two curl options each, so that you could write this: $ch = new CurlHandle('https://example.com'); $ch->setMethod('POST'); $ch->setRequestBody('{"stuff":"here"}'); $ch->setBasicAuth('admin', 'correct-horse-battery-staple'); $result = $ch->executeAndReturn(); Note that I am not saying every one of those methods needs to be added right now; adding a few at a time may be sensible to have time to discuss good names and signatures. But to me, renaming CURLOPT_POSTFIELDS to Curl\StringOptionsEnum::POSTFIELDS doesn't get us very far - users shouldn't need a raw curl setting for such a basic feature in the first place. Regards, -- Rowan Tommins [IMSoP]