Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106509 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 20156 invoked from network); 10 Aug 2019 00:02:44 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 10 Aug 2019 00:02:44 -0000 To: internals@lists.php.net References: Date: Fri, 9 Aug 2019 22:30:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Posted-By: 94.4.34.143 Subject: Re: [PHP-DEV] P++: FAQ From: markyr@gmail.com (Mark Randall) Message-ID: 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