On 16 June 2022 09:10:08 CEST, Pierrick Charron <pierr...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
