On 24/05/2025 21:24, Rob Landers wrote: > > > On Sat, May 24, 2025, at 19:42, Niels Dossche wrote: >> Hi >> >> In my opinion, the return type should not be nullable. >> Returning NULL when the platform (or PHP on that platform) doesn't support >> getting this information is an anti-pattern. >> Instead, availability of the necessary functionality should be checked at >> configure time and the function should be made conditionally available. >> That way, the return type can just be "int". >> >> Kind regards >> Niels >> > > I’m curious why you say this is an “anti pattern”? I do agree that it should > return a number or throw.
If you make the function unconditionally available, yet specifying the return type as ?int, then you give the false impression that it _can_ work even if your platform doesn't support it. Also: IMO new APIs should fail hard with an exception if they can't do their main task, that's our error "channel". > There are various error conditions it should throw (at least on Linux) so > having it throw an exception when there isn’t a way to count any processors > makes more sense than returning null. Throwing is indeed preferable. What are the error conditions on Linux? > > It could also be someone patching libc to get around per-core licensing too. > I’ve seen the latter more often than the former. I don't follow. In any case, if you run a monkey patched libc and you're breaking the consumer expectations of said libc, then you deserve getting it blown up in your face imo. Kind regards Niels
