Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106487
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=GsAqOXKDR9kxSwurDWhfk79rKKUZfCkKOiRdc6KNwcUU8zzGCoYkcvAMQO5psB
	MWrZT6w7aSWdWmY5s5ecTGSm7g6v1yLmekDxAz6AlKsxOEy6h74EX5W/IE8TUayK
	nyTp6PAjtcwoTXnVgudfEI/1vfBa9X/TF64bURnk1EGP0=;
MIME-Version: 1.0
References: <CAJHtznz+vMtytUxnf73L474TcDUqsZpTHLTnhHL4E53CCQdibA@mail.gmail.com> <CAF+90c-5CeZfyo2zBeoM63NDK-j2h6WTjvdT-yiKy040wVUm-w@mail.gmail.com> <CAJHtznzFSP4u7HggZPmyi27ejUie6x+kUytvTCd+WTpsKwFwag@mail.gmail.com> <CAF+90c8Ws-Ap2Ztw87gBS3bn_dKq+c+eNtAL90SCgqWhwsJCwA@mail.gmail.com> <CAKOpQSyWcge-6D9bu+bsJx=JdJ45MJd4KiqAuXzjQhTpWP4q0Q@mail.gmail.com> <f2841fb3-92e1-a700-9ed7-a3788b5d8bbd@korulczyk.pl>
In-Reply-To: <f2841fb3-92e1-a700-9ed7-a3788b5d8bbd@korulczyk.pl>
Date: Fri, 9 Aug 2019 15:39:55 +0300
Message-ID: <CAJHtznxTJT+LOYNLuwDyHyPai_=xZKNoUwYH4=zfP0JDM6_A4A@mail.gmail.com>
To: Robert Korulczyk <robert@korulczyk.pl>
Cc: Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005c696e058fae7993"
Subject: Re: [PHP-DEV] Bringing Peace to the Galaxy
From: zeev@php.net (Zeev Suraski)

--0000000000005c696e058fae7993
Content-Type: text/plain; charset="UTF-8"

On Fri, Aug 9, 2019 at 1:44 PM Robert Korulczyk <robert@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

--0000000000005c696e058fae7993--