As I understand, in P++ it was planned to drop the legacy code, add new functionality and painlessly implement BC.
Who wants – migrates the PHP project in P++, who doesn't – continues to use PHP. New projects, for example, will use P++ already. Well, how is this different from the new version of PHP (e.g. PHP 9)? Who wants – adapts his code for PHP 8/9 with all its BCs, who doesn't – continued to use PHP 7/8. Because this discussion flows smoothly from a neighboring branch, let me remind you that a few percentages of users who continue to use short tags were discussed there. Perhaps the same percentage of users will remain in PHP instead of the discussed P++. Will the development of a new language be justified due to the few percentages of users? — Sincerely, Sergey Panteleev https://s-panteleev.ru Telegram: @saundefined E-mail: ser...@s-panteleev.ru On 9 Aug 2019, 10:33 +0300, Kris Craig <kris.cr...@gmail.com>, wrote: > On Fri, Aug 9, 2019 at 12:22 AM Nikita Popov <nikita....@gmail.com> wrote: > > > On Thu, Aug 8, 2019 at 11:25 PM Zeev Suraski <z...@php.net> wrote: > > > > > > > > > > > On Fri, Aug 9, 2019 at 12:02 AM Nikita Popov <nikita....@gmail.com> > > wrote: > > > > > > > This is basically what I have been advocating for a while now already, > > > > somewhat hidden between all the other noise of the "namespace-scoped > > > > declares" thread. The model I would like to follow are Rust editions ( > > > > https://doc.rust-lang.org/edition-guide/editions/index.html). In PHP > > > > right now, the way to do this technically would be based on a > > > > declare(edition=2020) in every file. I was hoping to make this a > > > > per-package declaration instead, but haven't found the perfect way to do > > > > this right now. > > > > > > > > > > I think it's similar, but not quite the same, at least as far as what I > > > understood from what you were saying on that thread (I just reread it). > > > First, I think it's important we don't only focus on what we're going to > > > change - but also on what we're going to keep. The motivation should not > > > be slow eventual migration from one codebase to another. We would have > > > two, long-term supported codebases - a lot closer to C and C++ than to > > > different editions of a single language. The distance between them would > > > be quite substantial from the get-go - and will likely grow farther as > > time > > > goes by, similarly to the situation with C and C++. > > > > > > > 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. > > > > 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. > > > > Nikita > > > > > 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. > > --Kris
