Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106464 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 66297 invoked from network); 9 Aug 2019 02:25:41 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 9 Aug 2019 02:25:41 -0000 To: internals@lists.php.net References: <5d4ca16b.1c69fb81.bcb4a.9e51SMTPIN_ADDED_MISSING@mx.google.com> Date: Fri, 9 Aug 2019 00:52:56 +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] Re: Bringing Peace to the Galaxy From: markyr@gmail.com (Mark Randall) Message-ID: On 09/08/2019 00:08, Zeev Suraski wrote: > 2. Different people have different preferences. There's a reason that not > everyone is using the same language, or have the same mobile phone or the > same car. Something it's not 'forward' or 'backwards' - it's about > 'different'. Is C++ better than C? Many would argue that it is, while > others will argue that it's not. Both can be correct, it's ultimately not > only a matter of objective truths, but also subjective perceptions, > preferences and the tasks at hand. I'd say C++ gives you extra tools to do the job you want to do, and to do them quicker, and safer (std::string vs char[]). > 3. Putting your apparent personal bias against backwards compatibility > aside - if P++ goes in the directions you're hoping for - towards giving > you the goodies on your wish list, why would you care if PHP still existed > without these new changes/features? I'm not inherently biased against BC. But it doesn't exist in isolation, in my mind I have to weigh the benefits of BC with the benefits that breaking BC could bring. IMO, long term, the former is greatly outweighed by the latter. The thing is, I don't see PHP diverging in the way you suggest. I suspect it would end up being versioned within the same application, even though I suspect that would be much harder to pull off, it may end up that it's not actually possible. I was trying to think of something which could easily break if passed between two versions, and something which immediately came to mind was union types and reflection, a method which returned one string would need to return an array, or just the first, and so on. A "separate" version would certainly be easier. The ability to rip out everything which wasn't kept would no doubt simplify a lot of things, but I agree with Nikita's point that it only kicks things down the line until the next break. I think side-by-side engine versions are likely going to be the end result if it's possible. My heart says "clean break" my head says "side by side". Mark Randall