Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106493
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=b3Gx+XYb7uGk6GBkHhbXMIzl3yhd7ctHT4yTWYO00QZkBBk77DK5oOp6jAz+Le
	MIzCKLvp52a3K4OXs0ptworXAdW0FXQ58CZlcCBo7KrWn0sz56s+GY35Bm2bSzgB
	+KgZQHOHFnvq8H2J2MYHnpgl9iiFjUV4++ZLLNFlNDTbI=;
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>
In-Reply-To: <CAF+90c8Ws-Ap2Ztw87gBS3bn_dKq+c+eNtAL90SCgqWhwsJCwA@mail.gmail.com>
Date: Fri, 9 Aug 2019 16:25:03 +0300
Message-ID: <CAJHtznxHpmigMfRvvk6nwZke4cJg13VU2MMrJ9ju2-yT8bUUxA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000cdd851058faf1a6a"
Subject: Re: [PHP-DEV] Bringing Peace to the Galaxy
From: zeev@php.net (Zeev Suraski)

--000000000000cdd851058faf1a6a
Content-Type: text/plain; charset="UTF-8"

On Fri, Aug 9, 2019 at 10:22 AM Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Thu, Aug 8, 2019 at 11:25 PM Zeev Suraski <zeev@php.net> wrote:
>
> I think this part is unrealistic from a simple manpower perspective. We
> have something like ~2 full time developers working on PHP. Even if you can
> rally some additional interest around this idea, I don't think we have the
> resources to create a *substantially* different language in any reasonable
> amount of time. Doing feature additions and changes to PHP is Hard. Even
> simple changes require a fair bit of design and engineering effort to
> integrate with the large complexity of the existing language. This would
> not change for a hypothetical P++, because we still need to interoperate
> with PHP.
>

I think we should focus on the changes, and have additions as 2nd
priority.  We'll likely to get to some additions, just not all - it's fine
to add them at a later stage, like the following mini version.

Regardless of which direction we go for, it will probably be a good idea
for us to pause for a moment and think about what are the major issues we'd
want to address in PHP.  I don't think the list of *changes* is that long
that we can't pull off at least the majority of it in 2 years.  Factor in
the fact that instead of having heated discussions on internals@ and beyond
- about language fit and BC - we'd be able to focus exclusively on the best
solution for the problem - in the eyes of the folks in the 'strict' camp.


> Even if I agreed with the idea (which I'm pretty skeptical about in this
> particular form), I really don't think we have the resources to do
> something like this.


That may be, but I don't think that's the case.  Perhaps it would help if
we started a wiki page with topics that we'd want to address in such a
hypothetical project.  Strict ops, changes to type conversions, array
indices, variable declarations, etc.  I don't know that the list is *that*
 long.

Even if we go for your 'edition' approach (which by the way, isn't entirely
mutually exclusive from my idea - we could have these editions for P++ if
we thought it made sense) - our users would be a lot better served if we
handled the major BC breaks at first, as opposed to providing them in a
steady flow of breakage.  It would be a pretty lousy outcome if
PHP2020-native frameworks and apps became fundamentally broken when
upgrading to PHP2024.

Zeev

--000000000000cdd851058faf1a6a--