Re: P++: FAQ

From: Date: Fri, 09 Aug 2019 21:30:13 +0000
Subject: Re: P++: FAQ
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-106509@lists.php.net to get a copy of this message
On 09/08/2019 22:02, Sara Golemon wrote:
2. Strict(er) typing - I'm not sure, on the surface, what future expansions we'd plan for in this area which couldn't fit into standard PHP in a non BC-breaking way.
Union types and general reflection do spring to mind on this. I assume any APIs using them would need to return more complex objects describing them, rather than individual strings from getType(). Typed arrays are also another one which has been in high demand that I imagine will present some BC issues if shared between stricter and less-strict code. From what else I have read on here, the real biggy is probably going to be generics (hallowed by thy name).
3. Failing closed. Things like strpos() being able to return int(0) which is a falsey value. This has been a long standing "complaint" about PHP which isn't actually "fixable" without a big BC fail. We've already shown we're willing to bite this bullet for security issues (openssl_random_bytes).
strpos returning 0 for the start makes perfect sense to me, what doesn't make sense is returning false. I think these problems need to be murdered-to-death with scalar objects (ideally returning -1 or, at a push, null, because at least the return type could be expressed as ?int, but IMO -1 is far superior). I think scalar would be a huge game changer for allowing more sensible function names / return types without completely killing backwards compatibility on the existing core functions. The entire argument order issue could potentially be wrote off with SON. My guess is that whatever happens, it's going to require one version that really brings the pain, to set the groundwork for the future. Mark Randall

« previous php.internals (#106509) next »