Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106470 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 42665 invoked from network); 9 Aug 2019 09:47:56 -0000 Received: from unknown (HELO tbjjbihbhebb.turbo-smtp.net) (199.187.174.11) by pb1.pair.com with SMTP; 9 Aug 2019 09:47:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=php.net; s=turbo-smtp; x=1565939716; h=DomainKey-Signature:Received: Received:MIME-Version:References:In-Reply-To:From:Date: Message-ID:Subject:To:Cc:Content-Type; bh=UyueeHb0cTNWi6C4BVLUv8 Xnz06p/ZNbEEIB5NXUe0g=; b=cz2c6h2WsJrl4rKqrZ4Aqcj2h+080sBE+iRgGw iRfCvbcYn59GXDF4TcWkyffhKo8BwN62PTSXHz/M3rRFfpJkoWchX3CdV04UeGnK iThvsAuQn+SIZtE4gLXMhhoQGmvIcm2dvOnLmR683W8FCjxsRa6xrvTsFyroygU5 cJ2+Q= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=turbo-smtp; d=php.net; h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type; b=P8y/ABBw81Jfvyq+2t59OxIL+vLwk4om4MPIQRyWw+GdMKnFQ28+7vKq1NZHYx O/h2N/1656HsOm7dRXi5MmLtDMVtvzt9gPNwAUQ6WbNgHc4z3HZ6mQrO75MPRdwt 8IxWWOiosftAbG8N5BOnGxja3VF1n2/C49bhzVilgp6vk=; Received: (qmail 31743 invoked from network); 9 Aug 2019 07:15:16 -0000 Received: X-TurboSMTP-Tracking: 5212862335 X-Gm-Message-State: APjAAAX78B87jrURDtaVx84DuAXC1Mgh+pTJQTh1saH6F5la+wQQbtcT OI691XWlGGUVbZdn1bzgrU6sP/gz/gNaP5+KsNc= X-Google-Smtp-Source: APXvYqzhpmFUt/8YNQRRfpvoVJn4wmkO2qg/0YTUQKbmK588sM8N/2lzkJaUbi1/aVHbl7jceHF6J8D0y3t2lzdoVxc= X-Received: by 2002:ac8:6683:: with SMTP id d3mr16507479qtp.86.1565334915866; Fri, 09 Aug 2019 00:15:15 -0700 (PDT) MIME-Version: 1.0 References: <5d4ca16b.1c69fb81.bcb4a.9e51SMTPIN_ADDED_MISSING@mx.google.com> <5d4cb5da.1c69fb81.5608d.7c4bSMTPIN_ADDED_MISSING@mx.google.com> In-Reply-To: <5d4cb5da.1c69fb81.5608d.7c4bSMTPIN_ADDED_MISSING@mx.google.com> Date: Fri, 9 Aug 2019 10:15:04 +0300 X-Gmail-Original-Message-Id: Message-ID: To: Mark Randall Cc: Internals Content-Type: multipart/alternative; boundary="0000000000009d682d058fa9ef34" Subject: Re: [PHP-DEV] Re: Bringing Peace to the Galaxy From: zeev@php.net (Zeev Suraski) --0000000000009d682d058fa9ef34 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 9, 2019 at 2:53 AM Mark Randall wrote: > 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[]). > This might be exactly the point. You seem to believe that C++ is inherently superior to C. And it's entirely within your right. However, there are projects - to this date - that prefer C to C++ for a variety of reasons. PHP is one of them, and others include the Linux kernel, redis, nginx, and actually - the vast majority of the fundamental pieces of OS infrastructure our planet runs on. This isn't just for historical reasons - it has to do with a variety of reasons, and the simplicity of C is one of them. In the same way that C developers would resist if someone tried to go on a mission to convert them all to C++ developers - there's a big crowd in the PHP space that would resist some (many) of the things you think are absolutely awesome. The thing is - both of you can be right at the same time - as long as neither side is missionary about their position. > 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. We *all* agree. That's the 3rd thing I meant to write and forgot to ("I want to state 3 things and ask another", followed by only 3 items :)). IMO, long term, the former is greatly > outweighed by the latter. > Here we don't all agree. If the benefit is marginal to non-existent - than even when multiplied across decades - it remains marginal to non existent. That's why the position of the more BC-conscious crowd is that each BC break needs to have a good case with tangible benefits. It's always relative - not absolute. 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'm actually not following what you're saying here, and would appreciate it if you could further explain. But even without entirely understanding what you meant - my guess is that somewhat like C and C++ - these two flavors would cater to different people and different projects. Some frameworks are likely to embrace P++ and declare that their next version is going to be based on that. Others (such as Laravel, apparently) are likely to state they want nothing of it, and would stick with dynamic PHP for the long haul. In turn - end users will also be able to choose whether they stick with PHP for the long haul, keep their PHP investments and start using P++ for their next project, or migrate entirely to P++. All three are viable long term options. And with my approach - you can mix and match the two - so a PHP app can use a P++ framework, a PHP app may expose a P++ plugin API, etc. 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. > Passing these types of things across barriers will likely simply not make a lot of sense. It won't be a matter of it breaking - it'll simply not make sense. There'll likely be no issue calling PHP from P++; And PHP code will be exposing APIs using data types that it has, and not ones that it doesn't. Much like C++ developers often call into C (always, in fact, either directly or indirectly)- that's not an issue at all. > 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". I'm unable to follow that part either. Would appreciate some further elaboration to make it clearer what you have in mind in these three paragraphs... Thanks for the feedback! Zeev --0000000000009d682d058fa9ef34--