On Fri, Aug 9, 2019 at 10:22 AM Nikita Popov <nikita....@gmail.com> wrote:
> On Thu, Aug 8, 2019 at 11:25 PM Zeev Suraski <z...@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
