On Sat, Aug 10, 2019 at 6:21 PM guilhermebla...@gmail.com < guilhermebla...@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
