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

Hi Sara Den tors. 15. feb. 2024 kl. 21.08 skrev Sara Golemon <pollita@php.net>: > * 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. What about making the CURL options an enumeration? It would allow us to typehint the setOptions() method and we can also make it backwards compatible with the existing global constants: ```php public function setOption(CurlOption|int $option, mixed $value): static { if (is_int($option)) { $option = CurlOption::createFromConstant($option); } // ... } ``` The enumeration would then have a static method to transform the global constant into a native type (which we can do internally). Naming is obvious just TBD. The biggest potential issue I can see with this approach is the many conditionally defined constants from older CURL versions/feature flags from compile time. From the many type variants of setOptions(), I am uncertain about that, because with an enumeration, we would still need to have some sort of whitelisting of what options can be passed into the method. -- regards, Kalle Sommer Nielsen kalle@php.net