Summarizing replies so far. Won't be able to update the RFC immediately as my day job needs me, but some great discussions already, gang. Thanks!
* Define the conditions under which exceptions will be thrown (and which exceptions) - I'll add these to the RFC, but in short: * CurlException - Never, it's an interface type to group the other exceptions. * CurlHandleException - Whenever a CurlHandle::method() fails (in lieu of returning false) * CurlMultiException - Same, but for the CurlMultiHandle class. * CurlShareException - Same, but for the CurlShareHandle class. * Naming styles, e.g getErrorNumber(): int vs errno() Comment: Agreed with your points. We don't have to stick to a hard line mapping of the function names. My initial translation did because my bugbear is with the lack of fluency and all the rest is just window dressing on that. Proposal: I'll rename all the new APIs according to a get*/set* scheme without abbreviations, e.g.: * CurlHandle::getErrorNumber(): int * CurlHandle::getError(): ?string * static CurlHandle::getErrorTextFromCode(int $code): ?string * CurlHandle::execute(): ?string // See late note about exec return values * CurlHandle::setOptionInt(int $option, int $value): CurlHandle * Better typing for setOpt() methods. Comment: Yep, this is a good and fair point. It's going to take a little more dicing up of the current implementation, but hopefully not too rough. Proposal: Keep untyped setOption() method (1/ Easier migration of existing code, 2/ Some options may prove difficult to type), but add: * CurlHandle::setOptionBool(int $option, bool $value): CurlHandle * CurlHandle::setOptionInt(int $option, int $value): CurlHandle * CurlHandle::setOptionString(int $option, string $value): CurlHandle * etc... as needed, will this get weird when we get to Array since there IS a setOptArray? Maybe we just don't mirror that one, or we call it setOptionMany(). Yeah, I like Many for the multiple option set, and Array for the single option of array type. Internally, the setopt handler will be split by type so that each typed setting can call explicitly, and the untyped one can call all. * CurlHandle::exec() mixed typing of return values. Comment: Agreed. The `true` return value becomes meaningless in the RETURNTRANSFER==false case. Proposal: Update the RFC for CurlHandle::execute() to return ?string. * https://php.watch/articles/php-curl-security-hardening Comment: I'll read this later when I'm updating the RFC. * Prefer class constants to global constants. Comment: I'm less compelled by this. The global scope is polluted with the constants whether we add copies or not. Adding a second way to spell the constant name only adds a second way to spell the constant name. Proposal: Change my mind? * Request and Response objects, along the lines of PSR-18 Comment: I'd be in favor of that, but it's not the mountain I'm personally trying to climb today. No offense taken if you vote no because this isn't enough, but I don't have the cycles to go in that hard. Proposal: Write an RFC (and get it passed) and I can probably help you implement it? -Sara
