Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106541
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=gVVINMdIa7Sb792zU/NNh7XTfWES3g3mwTiPymx15Mp61XqBj5pKGIo2Ot+KuN
	IuQ7JE1UjDP5O1Bpx1s5c/CtDZAeFjKoTNq6fJF9Tf1WvvByHNNR2qFT6CT3A+W7
	zKQZsrZatPmb3A2aciDi0clLl3F5wZVNNmWsDKXXEj0dQ=;
MIME-Version: 1.0
References: <CAJHtznw0eKbBNJo9TnDwZvvbMMFt5mCo=+SpKLw0zYzq9tKWZA@mail.gmail.com> <5d4e9057.1c69fb81.bdf14.8d8fSMTPIN_ADDED_MISSING@mx.google.com> <CACXBjuhfzX8vDXoJx2Q7EKQUu-2io=7+DyhCpWupt_8r15ijTg@mail.gmail.com> <CAFp73Xua7kmd4NKOpK_hyiNRDxcf7Xg_3Q+WRQtO4muaWHiypA@mail.gmail.com>
In-Reply-To: <CAFp73Xua7kmd4NKOpK_hyiNRDxcf7Xg_3Q+WRQtO4muaWHiypA@mail.gmail.com>
Date: Sun, 11 Aug 2019 13:36:20 +0300
Message-ID: <CAJHtznyccfSJYEGSs66ADFZFW4atg5oPJRXdO9shkF2sfop1dA@mail.gmail.com>
To: "guilhermeblanco@gmail.com" <guilhermeblanco@gmail.com>
Cc: Rasmus Lerdorf <rasmus@lerdorf.com>, Andrea Faulds <ajf@ajf.me>,  PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000fff7bd058fd4fa4d"
Subject: Re: [PHP-DEV] Re: P++: FAQ
From: zeev@php.net (Zeev Suraski)

--000000000000fff7bd058fd4fa4d
Content-Type: text/plain; charset="UTF-8"

On Sat, Aug 10, 2019 at 6:21 PM guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:

> 1- How would you envision a shared runtime between PHP and P++, in the
> case that this new evolved solution decides to support objects as keys
> in array structure? This fundamentally changes internals, and a
> drastic change to both runtime of PHP and P++ would be required.
>

Why would that only make it into P++ and not PHP?  Things which are
sensible to both dialects should go into both dialects.

2- How would you envision injecting an actual namespace structure,
> allowing scoping support for namespaces? FYI, this is what blocked me
> to finish class visibility in https://github.com/php/php-src/pull/947
> It'd require drastic changes in both PHP runtime and P++ too.
>

I don't think we have an answer for that, but I also think it's an
orthogonal question.  It applies at the exact same way to the Editions.

The only I see this to operate is either P++ re-implementing the same
> PHP structures in order to evolve, leading to a full fork becoming
> more attractive, or compromises in P++ (like unable to support a given
> feature) because PHP would make it set back.
>

While I think that the deltas would be a lot smaller than something we
should lose sleep over in terms of maintenance overhead - this will
primarily depend on the substance of what we'd want to change - and not on
how we package it.  Whether we go for feature-specific declare()s,
Editions, or P++ - makes little to no impact on the complexity of the code
base.  In fact, if anything - having an all-or-nothing option is likely to
make the engine code simpler to develop and maintain, as instead of a huge
number (per-feature) or medium number (Editions) of combinations that need
to be designed to work together, supported and tested - we'd have just two.

Do you view this differently?

Thanks for the feedback!

Zeev

--000000000000fff7bd058fd4fa4d--