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]

Reply via email to