Re: Discussion about new C url URL API and ext/curl improvements

On 16 June 2022 09:10:08 CEST, Pierrick Charron <pierrick@php.net> wrote: > [...] >- For consistency expose the new Curl URL API as functions mapped one to >one to libcurl functions : > >function curl_url(?string $url = null): CurlUrl|false {} >function curl_url_set(CurlUrl $url, int $part, string $content, int $flags >= 0): bool {} >function curl_url_get(CurlUrl $url, int $part, int $flags = 0): >string|false {} >function curl_url_errno(CurlUrl $url): int {} >function curl_url_strerror(int $error_code): ?string {} > >- Add methods to the CurlUrl object to make it less opaque and expose an >object oriented style API. I would keep it minimal and let userlanAd API >provide higher level APIs as guzzle for example. (You can see the current >implementation [5]) > >final class CurlUrl implements Stringable >{ > public function __construct(?string $url = null) {} > public function get(int $part, int $flags = 0): string {} > public function set(int $part, string $content, int $flags = 0): void {} > public function getErrno(): int {} > public function __toString(): string {} > public function __clone() {} >} Hello, When IntlDatePatternGenerator was implemented, I initially also supplied both a procedural and OO-style API, but was told that this duplication was historical and not necessary for new APIs. See the thread following this message: [1] I would argue that this also applies to curl, and that it might make sense to only supply the OO-style API here as well. (With curl_url_strerror being exposed as either a static method on CurlUrl or as getErrorMessage, I suppose.) >- It would also be nice to add this object oriented API for existing >CurlHandle, CurlMultiHandle and CurlShareHandle classes. For example the >CurlHandle class would look like that (First implementation [6]) I think this would be a good idea either way. Regards, Mel [1] https://externals.io/message/114473#114658