On Fri, Aug 9, 2019 at 1:44 PM Robert Korulczyk <rob...@korulczyk.pl> wrote:
> > I think it should also be pointed out that there's nothing stopping > anyone > > from forking PHP into a new project as Zeev described and maintain > feature > > parity. As I understand, the reason something like this hasn't happened > > already is because it would involve a ton of work and nobody wants to > deal > > with it. But if you or anyone else does manage to put a team together > and > > make something like this happen as a separate project, I'd certainly have > > no objection. > > It does not need to be a fork. AFAIK there is no technical obstacle to > extend lifetime of particular version on PHP and create some kind of LTS > line. > For example, PHP 7.4 could be supported for 10-20 years (probably with > security patches only), so everyone who has "legacy - do not touch it!" code > can stick to 7.4 line. Everyone else could just move on and use PHP 8 with > all new features and BC breaks. > > Kris, Robert, I'm not sure what you're saying here exactly, but if you are suggesting that PHP.future, whatever this future version number is - is going to be a strictly typed language, with total disregard for BC - as folks who want to go on using and developing for the dynamic version of PHP, and/or want their existing humongous code bases to go on working - are forced to stick around with a dead-end version of the language, then no, it is simply not going to happen, ever. I think it would be a lousy outcome, but if that's what the "strict camp" wants, it's going to have to be that camp that forks. Whether it's a fork or LTS - this is a *radical* duplication of effort. The language engine is just one element - extension development, bug fixes, security fixes - all of these are critically important in order for either of these projects. If the two diverge - except for the immediate near term, these efforts would effectively have to happen twice, separately for each project. Because I think it's a lousy outcome for everyone - we should (IMHO) take it off the table, and focus on other outcomes that don't involve forking or de-facto forking (unlimited-term LTS). I believe my solution gives both camps virtually all of what they want - with perhaps the lack of indulgence of some missionary elements in the pro-change/strict/anti-BC camp. Since the dynamic camp isn't going anywhere, we really have two options - come to terms that there'll never be a fully strict version of PHP, or create some sort of mechanism to allow for both. Both Nikita's idea and mine are a form of the latter, although it *seems* Nikita's idea does have a long term goal of moving people - gently and not so gently - towards strict (over a long period of time). My idea treats both these dialects as equal among equals - and IMHO, also has some other advantages as far as clear messaging, market perception and potentially also maintainability. Zeev
