# Bringing Peace to the Galaxy - Thread: https://externals.io/message/106453 - Original archive: https://news-web.php.net/php.internals/106453 - Started by Zeev Suraski on 2019-08-08T20:17:04+00:00 - Messages: 53 - Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/106453.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #106453 — Zeev Suraski — 2019-08-08T20:17:04+00:00 URL: https://externals.io/message/106453#106453 [... and not in the Sith Lord kind of way.] Looking at some of the recent (& not so recent) discussions on internals@, some of the recent proposals, as well as some of the statements made regarding the future direction of the language - makes it fairly clear that we have a growing sense of polarization. As Peter put it yesterday (I may be paraphrasing a bit) - some folks just want to clear some legacy stuff. I think that in practice it goes well beyond that - many on internals@ see parts of PHP as in bad need of repair (scoop: I agree with some of that), while other capabilities, that exist in other competing languages - are - in their opinion - sorely missing. At the other end of the spectrum, we have folks who think that we should retain the strong bias for downwards compatibility we always had, that PHP isn't in dire need of an overhauling repair and that as far as features go - less is more - and we don't have to race to replicate features from other languages - but rather opt for keeping PHP simple. To a large degree, these views are diametrically opposed. This made many internals@ discussions turn into literally zero sum games - where when one side 'wins', the other side 'loses', and vice versa. It's fair to say that I'm a lot closer in the way I view things to the latter camp that the former one. But, at the same time - I understand that there's merit to the other POV. Even when my POV 'wins', it often feels as a bit of a Pyrrhic victory, as the negative vibes from these zero sum discussions and the feeling of disappointment felt by folks in the other group - many of which I have very high respect for - are definitely not good for the project (I hope that at least some of them feel in the same way when things happen in reverse). Now, what if there was a way to truly make both 'camps' happy? I think there may be. There are several successful examples for how languages evolved dramatically while doing exactly that - retaining downwards compatibility while introducing radical changes - including compatibility breaking ones - at the same time. The most obvious example that comes to mind if C++. It's a whole new language, that clearly borrows a much of its basic syntax from C, but also adds many fundamental new features on top of it - and changes behavior in many situations. When I say that C++ is compatible with C - it's not that you can run (or compile) any given piece of C code on C++ - you definitely cannot - but you can call C code from C++ code fairly transparently, and you wouldn't have to change anything at all in your C code. If you have a piece of code written in C and you don't care about C++ - you don't have to do anything at all. In the same way, if you're a C developer, and don't care much for C++ - you're not forced to learn it - as long as you work on C-based projects. That will never change. Another somewhat similar example is ES6 - where a lot of new capabilities are added without breaking anything about the underlying ES5. By now I think the idea should be obvious - what if we did something similar for PHP? Essentially - radically slow down the amount of language-level (read: syntax) changes - both additions, deprecations and modifications in PHP itself; But, simultaneously - make the engine understand a new flavor of the language (phure? phun? phlex? phuture?) - a flavor where we'd in fact be able to introduce a wide range of changes overnight - a lot more rapidly than even folks in the former camp feel comfortable doing today. Since the vast majority of contention between the two camps has to do with either downwards compatibility or 'language fit' - introducing a new flavor of the language, which is available in addition to the current one instead of replacing it - can provide a fundamental solution to both of these points of contention. We actually have a substantial advantage over both of the above-mentioned language sets (C/C++ and JS/ES6) as for all practical purposes - we control the single relevant implementation of the language. At this point - I also see no reason of why that implementation wouldn't be able to handle both flavors of the language - sharing the same compiler and runtime - and allowing them to run simultaneously alongside each other, in a similar way that C++ code can run and interoperate with C code at runtime, despite being substantially different languages. The runtime will simply know how to run in two different modes - depending on the file at hand - similarly to how we do strict types (and we could probably entertain other options as well, like doing it on a namespace level). I want to illustrate what I think this will buy us, at least from my POV. In P++ (temp code name) - we'd be able to get rid of elements that have little going for them other than backwards compatibility - such as short tags (not sure about hebrev :)). But more importantly - we could make much more radical changes a lot more quickly. Since migration would be opt-in - we won't have to worry about breaking people's code, and will be able to (and probably should) introduce all of these things overnight, so that they're a part of a consistent new paradigm and not a slow steady stream of breakage. We could (and probably should) make it strict from the get go - and not just with types - but also with ops, variable declarations, etc. We could change array behavior to differentiate between integers and integer-looking-numbers. And probably quite a few other things that currently bother some of us. And we could do all that without sacrificing compatibility. There's another advantage to doing that - it will allow us to rebrand. It's no secret that PHP has a negative reputation among many developers. Without getting into the question of whether it's justified or not - starting with something that's a lot closer to a clean slate - and under a different name - can make a much bigger impact than slow, gradual evolution under the same name (which, as I've been working hard to illustrate for a long time, also has substantial downsides). Now, the PHP (old/current) flavor won’t stagnate either - it will still benefit from evolution in extensions, other evolving pieces (like JIT or other improvements in the runtime) and security updates. Things which those who care primarily about keeping their code working, or that don’t care for an ever evolving stricter language (and there’s many of them) - will be able to continue enjoying. I admit, I haven't thought about every possible corner case we may have here, and it's still very raw. But at a high level, it seems to make a lot of sense to me, and I think the advantages of going in this direction - both technology related, and in restoring calm (and perhaps even renewing enthusiasm) around internals@ - are strong enough for us to brainstorm about it. Thoughts? Zeev --- ## #106454 — Nikita Popov — 2019-08-08T21:02:04+00:00 URL: https://externals.io/message/106453#106454 · In reply to: #106453 > [... and not in the Sith Lord kind of way.] > > Looking at some of the recent (& not so recent) discussions on internals@, > some of the recent proposals, as well as some of the statements made > regarding the future direction of the language - makes it fairly clear that > we have a growing sense of polarization. > > As Peter put it yesterday (I may be paraphrasing a bit) - some folks just > want to clear some legacy stuff. I think that in practice it goes well > beyond that - many on internals@ see parts of PHP as in bad need of repair > (scoop: I agree with some of that), while other capabilities, that exist in > other competing languages - are - in their opinion - sorely missing. > > At the other end of the spectrum, we have folks who think that we should > retain the strong bias for downwards compatibility we always had, that PHP > isn't in dire need of an overhauling repair and that as far as features go > - less is more - and we don't have to race to replicate features from other > languages - but rather opt for keeping PHP simple. > > To a large degree, these views are diametrically opposed. This made many > internals@ discussions turn into literally zero sum games - where when one > side 'wins', the other side 'loses', and vice versa. > > It's fair to say that I'm a lot closer in the way I view things to the > latter camp that the former one. But, at the same time - I understand that > there's merit to the other POV. Even when my POV 'wins', it often feels as > a bit of a Pyrrhic victory, as the negative vibes from these zero sum > discussions and the feeling of disappointment felt by folks in the other > group - many of which I have very high respect for - are definitely not > good for the project (I hope that at least some of them feel in the same > way when things happen in reverse). > > Now, what if there was a way to truly make both 'camps' happy? I think > there may be. > > There are several successful examples for how languages evolved > dramatically while doing exactly that - retaining downwards compatibility > while introducing radical changes - including compatibility breaking ones - > at the same time. > > The most obvious example that comes to mind if C++. It's a whole new > language, that clearly borrows a much of its basic syntax from C, but also > adds many fundamental new features on top of it - and changes behavior in > many situations. When I say that C++ is compatible with C - it's not that > you can run (or compile) any given piece of C code on C++ - you definitely > cannot - but you can call C code from C++ code fairly transparently, and > you wouldn't have to change anything at all in your C code. If you have a > piece of code written in C and you don't care about C++ - you don't have to > do anything at all. In the same way, if you're a C developer, and don't > care much for C++ - you're not forced to learn it - as long as you work on > C-based projects. That will never change. > > Another somewhat similar example is ES6 - where a lot of new capabilities > are added without breaking anything about the underlying ES5. > > By now I think the idea should be obvious - what if we did something > similar for PHP? > > Essentially - radically slow down the amount of language-level (read: > syntax) changes - both additions, deprecations and modifications in PHP > itself; But, simultaneously - make the engine understand a new flavor of > the language (phure? phun? phlex? phuture?) - a flavor where we'd in > fact be able to introduce a wide range of changes overnight - a lot more > rapidly than even folks in the former camp feel comfortable doing today. > Since the vast majority of contention between the two camps has to do with > either downwards compatibility or 'language fit' - introducing a new flavor > of the language, which is available in addition to the current one instead > of replacing it - can provide a fundamental solution to both of these > points of contention. > > We actually have a substantial advantage over both of the above-mentioned > language sets (C/C++ and JS/ES6) as for all practical purposes - we control > the single relevant implementation of the language. At this point - I also > see no reason of why that implementation wouldn't be able to handle both > flavors of the language - sharing the same compiler and runtime - and > allowing them to run simultaneously alongside each other, in a similar way > that C++ code can run and interoperate with C code at runtime, despite > being substantially different languages. The runtime will simply know how > to run in two different modes - depending on the file at hand - similarly > to how we do strict types (and we could probably entertain other options as > well, like doing it on a namespace level). > > I want to illustrate what I think this will buy us, at least from my POV. > > In P++ (temp code name) - we'd be able to get rid of elements that have > little going for them other than backwards compatibility - such as short > tags (not sure about hebrev :)). > > But more importantly - we could make much more radical changes a lot more > quickly. Since migration would be opt-in - we won't have to worry about > breaking people's code, and will be able to (and probably should) introduce > all of these things overnight, so that they're a part of a consistent new > paradigm and not a slow steady stream of breakage. We could (and probably > should) make it strict from the get go - and not just with types - but also > with ops, variable declarations, etc. We could change array behavior to > differentiate between integers and integer-looking-numbers. And probably > quite a few other things that currently bother some of us. And we could do > all that without sacrificing compatibility. > > There's another advantage to doing that - it will allow us to rebrand. > It's no secret that PHP has a negative reputation among many developers. > Without getting into the question of whether it's justified or not - > starting with something that's a lot closer to a clean slate - and under a > different name - can make a much bigger impact than slow, gradual evolution > under the same name (which, as I've been working hard to illustrate for a > long time, also has substantial downsides). > > Now, the PHP (old/current) flavor won’t stagnate either - it will still > benefit from evolution in extensions, other evolving pieces (like JIT or > other improvements in the runtime) and security updates. Things which > those who care primarily about keeping their code working, or that don’t > care for an ever evolving stricter language (and there’s many of them) - > will be able to continue enjoying. > > I admit, I haven't thought about every possible corner case we may have > here, and it's still very raw. But at a high level, it seems to make a lot > of sense to me, and I think the advantages of going in this direction - > both technology related, and in restoring calm (and perhaps even renewing > enthusiasm) around internals@ - are strong enough for us to brainstorm > about it. > > Thoughts? > > Zeev > 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 that introducing this kind of concept for PHP is very, very important. We have a long list of issues that we cannot address due to backwards compatibility constraints and will never be able to address, on any timescale, without having the ability of opt-in migration. I do plan to create an RFC on this topic. Nikita --- ## #106456 — Nikita Popov — 2019-08-08T21:22:15+00:00 URL: https://externals.io/message/106453#106456 · In reply to: #106454 > > > > […] > > 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 that introducing this kind of concept for PHP is very, very > important. We have a long list of issues that we cannot address due to > backwards compatibility constraints and will never be able to address, on > any timescale, without having the ability of opt-in migration. > > I do plan to create an RFC on this topic. > After reading your mail again, I think what I have in mind is maybe quite different from what you have in mind after all, even if the motivation and purpose (language evolution without breaking legacy code) is the same. In particular, you seem to have a pretty strong focus on introducing a "new" language with a new name that just happens to interoperate with PHP. I don't think that's a direction we should be going down. One of the larger issues with that is that it only works once: You have one BC break point going between PHP and PHP++, but that's it. Unless you want to rebrand your language every five years ;) What we need is something that is sustainable in the long term. I also don't like the idea of rebranding as a new language. While PHP has a bad reputation, I really don't think that introducing PHP++ will do anything positive to that. PHP should stay PHP. The core language should remain the same across all editions/epochs/whatever -- just with the possibility of addressing specific issues. As discussed in a recent thread, a new edition could require & annotations at call-sites and gain all the benefits that entails without breaking the ecosystem. Nikita --- ## #106457 — Zeev Suraski — 2019-08-08T21:25:05+00:00 URL: https://externals.io/message/106453#106457 · In reply to: #106454 > 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++. Also - I think that we should do our very best to get this "P++" right the first time, as opposed to iterate on it and release editions that provide a steady stream of change and breakage. Of course - we can add new features and evolve existing ones - but this should be a lot more similar to the mini versions / feature releases we currently have. It's certainly similar in concept, but not quite the same. Zeev --- ## #106458 — Zeev Suraski — 2019-08-08T21:58:47+00:00 URL: https://externals.io/message/106453#106458 · In reply to: #106456 > > > > […] > > After reading your mail again, I think what I have in mind is maybe quite > different from what you have in mind after all, even if the motivation and > purpose (language evolution without breaking legacy code) is the same. > I'd describe my motivations quite differently than that. First, I want to point out that my very first motivation was in fact a human one - hence the subject line. I think there's substantial value in finding a solution for the constant contention on internals, without neither camp giving up on their principals and beliefs. Secondly - the current language-base of PHP (7.x) won't be 'legacy'. I think there's going to be a lot of new code written in it, and I think a lot of people would prefer it over P++ - even in 5 or 10 years. Again, C/C++ is a very good analogy here. If one camp remains 'missionary' about forcing the other camp to assimilate as the long term goal - that's not at all what I'm talking about. This is also why an edition named 'PHP2020' is somewhat problematic - as it implies you're behind if you're not using it. My goal is to have two sister languages, with both PHP and P++ being equal among equals, and not PHP being the 'dead language walking' and P++ being the end goal of everything. In particular, you seem to have a pretty strong focus on introducing a > "new" language with a new name that just happens to interoperate with PHP. > Not quite - it doesn't just happen to interoperate with PHP. It shares the same runtime; It shares the same extensions; It shares many of the same tools; And most importantly - it's very similar in its syntax. Again, here too, the C/C++ analogy works really well. Would you say C++ is a new language that just happens to interoperate with C? It's obviously a lot more than that. I don't think that's a direction we should be going down. > Oh well :| > One of the larger issues with that is that it only works once: You have > one BC break point going between PHP and PHP++, but that's it. Unless you > want to rebrand your language every five years ;) What we need is something > that is sustainable in the long term. > I think that the one, big-scoped compatibility breakage is a feature, not a bug. At the risk of sounding like a broken record - the C/C++ analogy works well here too, this time specifically C++. You can evolve the new language - even substantially - but C++ always stayed C++ and C always stayed C. Yes, there's C++03, C++11, etc. - but at the end of the day - the language is C++, and these editions are similar to the evolution we introduce in feature releases. If your goal is to have major BC breaks every five years, then I doubt we can find common grounds. But I'm not sure how many folks here think that's a good idea either. There's a big gap between thinking we should break away from 20+ year old chains that are they're fundamentally unhappy about, and moving to a 'let's redo the language every five years'. > I also don't like the idea of rebranding as a new language. While PHP has > a bad reputation, I really don't think that introducing PHP++ will do > anything positive to that. PHP should stay PHP. The core language should > remain the same across all editions/epochs/whatever -- just with the > possibility of addressing specific issues. As discussed in a recent thread, > a new edition could require & annotations at call-sites and gain all the > benefits that entails without breaking the ecosystem. > I'm sorry to hear that. In this particular case I really think you're wrong (FWIW) - rebranding can actually do a lot of positive things. It can stir interest. It can result in articles being written. It can make developers, development leaders and companies who have ruled out PHP reconsider their decision since "this is no longer PHP". A new version of PHP, or for that matter a new edition of PHP - will simply not have the same impact. As much as we're all technical people here, marketing matters. And in this particular case - this type of positioning does make sense - as with many of the proposed changes - this really is no longer PHP. Another thing it can also do is radically simplify the end-user understanding of our vision of what goes where, and what's in store for PHP as we currently know it. I'm truly hopeful that others on the list (and perhaps you as well) evaluate this proposal with an open mind. I did run by a few folks (from the 'other' camp) prior to publishing it, and response was very positive. Thanks, Zeev --- ## #106459 — Mark Randall — 2019-08-08T22:25:44+00:00 URL: https://externals.io/message/106453#106459 · In reply to: #106453 > [... and not in the Sith Lord kind of way.] > Thoughts? I'm going to speak strictly as a userland PHP developer, for that is what I am. The idea of PHP being held hostage to eternal backwards compatibility fills me with absolute dread. I've built most of my career on PHP, I find it a very powerful platform, but I find it lacking in some major areas. Some of those have reasonable workarounds (React, Swoole) and some of them do not (var level type enforcement, generics, universal annotations, first class functions and other symbols, union types, CoW classes etc). I hope that some day, these problems are going to be fixed, but in the process I understand they may pose backwards compatibility issues. If PHP as a language cannot push forwards out of a concern for perpetual backwards compatibility, then I have to start questioning if it makes sense for me, and those I work with, to continue using it in the long run, vs a platform which is willing to find a way to make those changes and push things forward. I'm thinking 5 - 10 years here. As a developer, having to spend time on fixing BC breaks is obviously a cost. However, not having things that would have saved me time, or allowed me to write better code if they were there, but weren't added because of BC, is also a cost. To my mind, I would be happy to see a situation where I can stick a declare in my file that says "Give me the good stuff and I will find a way to deal with the BC breaks". I can deal with short term pain for long term gain. What I would struggle to deal with is committing myself and my clients to a language and ecosystem where history was constantly allowed to trump pragmatism. I understand it's obviously a big challenge for the internals team and its contributors to create coexistent systems with versioning, but I would simply offer the following: If you're not going forward, you're falling behind, and sometimes going forward requires sacrifice. Mark Randall --- ## #106460 — Zeev Suraski — 2019-08-08T23:08:20+00:00 URL: https://externals.io/message/106453#106460 > > > […] > > The idea of PHP being held hostage to eternal backwards compatibility > fills me with absolute dread. > [snip] > If you're not going forward, you're falling behind, and sometimes going > forward requires sacrifice. > > Mark, I'd like to state three things, and ask another: 1. The differences between the internals@ schools of thought aren't limited to just downwards compatibility issues alone - these were highlighted because of the recent short tags discussion, but that's just one aspect out of several - which I mentioned in my message. 2. Different people have different preferences. There's a reason that not everyone is using the same language, or have the same mobile phone or the same car. Something it's not 'forward' or 'backwards' - it's about 'different'. Is C++ better than C? Many would argue that it is, while others will argue that it's not. Both can be correct, it's ultimately not only a matter of objective truths, but also subjective perceptions, preferences and the tasks at hand. 3. Putting your apparent personal bias against backwards compatibility aside - if P++ goes in the directions you're hoping for - towards giving you the goodies on your wish list, why would you care if PHP still existed without these new changes/features? Zeev --- ## #106461 — Benjamin Morel — 2019-08-08T23:08:42+00:00 URL: https://externals.io/message/106453#106461 > > I'm going to speak strictly as a userland PHP developer, for that is > what I am. > The idea of PHP being held hostage to eternal backwards compatibility > fills me with absolute dread. > (...) > I can deal with short term pain for long term gain. > What I would struggle to deal with is committing myself and my clients > to a language and ecosystem where history was constantly allowed to > trump pragmatism. > I understand it's obviously a big challenge for the internals team and > its contributors to create coexistent systems with versioning, but I > would simply offer the following: > If you're not going forward, you're falling behind, and sometimes going > forward requires sacrifice. This could not better match my feelings. I've been a userland PHP developer for the last 15 years, have quite a trail of code behind me, and would also love to deal with BC breaks. No pain no gain. Benjamin > > > […] > > I'm going to speak strictly as a userland PHP developer, for that is > what I am. > > The idea of PHP being held hostage to eternal backwards compatibility > fills me with absolute dread. > > I've built most of my career on PHP, I find it a very powerful platform, > but I find it lacking in some major areas. Some of those have reasonable > workarounds (React, Swoole) and some of them do not (var level type > enforcement, generics, universal annotations, first class functions and > other symbols, union types, CoW classes etc). > > I hope that some day, these problems are going to be fixed, but in the > process I understand they may pose backwards compatibility issues. > > If PHP as a language cannot push forwards out of a concern for perpetual > backwards compatibility, then I have to start questioning if it makes > sense for me, and those I work with, to continue using it in the long > run, vs a platform which is willing to find a way to make those changes > and push things forward. I'm thinking 5 - 10 years here. > > As a developer, having to spend time on fixing BC breaks is obviously a > cost. However, not having things that would have saved me time, or > allowed me to write better code if they were there, but weren't added > because of BC, is also a cost. > > To my mind, I would be happy to see a situation where I can stick a > declare in my file that says "Give me the good stuff and I will find a > way to deal with the BC breaks". > > I can deal with short term pain for long term gain. > > What I would struggle to deal with is committing myself and my clients > to a language and ecosystem where history was constantly allowed to > trump pragmatism. > > I understand it's obviously a big challenge for the internals team and > its contributors to create coexistent systems with versioning, but I > would simply offer the following: > > If you're not going forward, you're falling behind, and sometimes going > forward requires sacrifice. > > Mark Randall --- ## #106462 — Matthew Brown — 2019-08-08T23:37:27+00:00 URL: https://externals.io/message/106453#106462 · In reply to: #106460 > 3. Putting your apparent personal bias against backwards compatibility > aside - if P++ goes in the directions you're hoping for - towards giving > you the goodies on your wish list, why would you care if PHP still existed > without these new changes/features? > > Zeev > Another userland developer here. I'd just like to share my abject terror of the idea that the language might split into two. Having made a toy transpiler (https://github.com/hacktophp/hacktophp) from Hack code to PHP, I don't think that's a good way forward either. The Python 2 => 3 migration is a good example of a language maintaining its popularity despite an uncomfortable upgrade, and I think that bump has helped secure Python's relevance for the next decade. Though PHP is uncool, it's still popular. Have faith that the community won't abandon PHP if the language improves. --- ## #106463 — Todd Ruth — 2019-08-08T23:43:15+00:00 URL: https://externals.io/message/106453#106463 · In reply to: #106460 > ... > 3. Putting your apparent personal bias against backwards compatibility > aside - if P++ goes in the directions you're hoping for - towards giving > you the goodies on your wish list, why would you care if PHP still existed > without these new changes/features? > > Zeev I just want to express a personal bias - joy at reading the proposal. Our php code goes back to approx 2002. We did get a performance improvement moving to PHP7 and it has allowed us to integrate with third party modules that were not compatible with PHP5, but it also required many, many hours that were not spent moving our application forward in other ways. I think the #1 reason for changing PHP versions for us is security policy. If a PHP version is "end of life" we must move on, no matter how much pain it causes and how perfectly acceptably everything was functionally running on the older version. The idea of having code that works be allowed to continue to work is very, very appealing. I don't want people who want to go in bold new directions to be held back; the proposal seems like something that would help me sleep more peacefully while allowing the adventurous to proceed. Thanks! - Todd (usually quiet here) --- ## #106464 — Mark Randall — 2019-08-08T23:52:56+00:00 URL: https://externals.io/message/106453#106464 · In reply to: #106460 > 2. Different people have different preferences. There's a reason that not > everyone is using the same language, or have the same mobile phone or the > same car. Something it's not 'forward' or 'backwards' - it's about > 'different'. Is C++ better than C? Many would argue that it is, while > others will argue that it's not. Both can be correct, it's ultimately not > only a matter of objective truths, but also subjective perceptions, > preferences and the tasks at hand. I'd say C++ gives you extra tools to do the job you want to do, and to do them quicker, and safer (std::string vs char[]). > 3. Putting your apparent personal bias against backwards compatibility > aside - if P++ goes in the directions you're hoping for - towards giving > you the goodies on your wish list, why would you care if PHP still existed > without these new changes/features? I'm not inherently biased against BC. But it doesn't exist in isolation, in my mind I have to weigh the benefits of BC with the benefits that breaking BC could bring. IMO, long term, the former is greatly outweighed by the latter. The thing is, I don't see PHP diverging in the way you suggest. I suspect it would end up being versioned within the same application, even though I suspect that would be much harder to pull off, it may end up that it's not actually possible. I was trying to think of something which could easily break if passed between two versions, and something which immediately came to mind was union types and reflection, a method which returned one string would need to return an array, or just the first, and so on. A "separate" version would certainly be easier. The ability to rip out everything which wasn't kept would no doubt simplify a lot of things, but I agree with Nikita's point that it only kicks things down the line until the next break. I think side-by-side engine versions are likely going to be the end result if it's possible. My heart says "clean break" my head says "side by side". Mark Randall --- ## #106467 — Brent — 2019-08-09T05:11:52+00:00 URL: https://externals.io/message/106453#106467 · In reply to: #106458 Hi Zeev Happy to see this proposal pop up, it's good to know that the "other side" is also open for long-term solutions. I think there needs to be a thorough analysis about the pros and cons of the two paths to take: a sister language vs. Nikita's proposal. To me, a userland developer, both solutions would have the same result in the end, so I trust internals to make a well-informed decision. There's one thing I haven't seen mentioned yet though: what about the added workload for the core developers? You'll have to maintain two implementations of PHP, be it in the same runtime. Is this a load the core developers are able to carry? Aren't you afraid that development of the "old" version of PHP would quickly decline? If that were to happen, there's little difference in tagging a new major release with the breaking changes/cleanup we want. Lastly, how do you envision interop between this two sister languages? Would a "normal" composer package be able to run in P++ ? You did mention P++ would share the same runtime, extensions, etc, but whether the runtime would be able to switch between the old and new version depending on the code wasn't clear to me. Kind regards Brent > > > > […] > > I'd describe my motivations quite differently than that. > > First, I want to point out that my very first motivation was in fact a > human one - hence the subject line. I think there's substantial value in > finding a solution for the constant contention on internals, without > neither camp giving up on their principals and beliefs. > > Secondly - the current language-base of PHP (7.x) won't be 'legacy'. I > think there's going to be a lot of new code written in it, and I think a > lot of people would prefer it over P++ - even in 5 or 10 years. Again, > C/C++ is a very good analogy here. If one camp remains 'missionary' about > forcing the other camp to assimilate as the long term goal - that's not at > all what I'm talking about. This is also why an edition named 'PHP2020' is > somewhat problematic - as it implies you're behind if you're not using it. > > My goal is to have two sister languages, with both PHP and P++ being equal > among equals, and not PHP being the 'dead language walking' and P++ being > the end goal of everything. > > In particular, you seem to have a pretty strong focus on introducing a > > […] > > Not quite - it doesn't just happen to interoperate with PHP. It shares the > same runtime; It shares the same extensions; It shares many of the same > tools; And most importantly - it's very similar in its syntax. Again, > here too, the C/C++ analogy works really well. Would you say C++ is a new > language that just happens to interoperate with C? It's obviously a lot > more than that. > > I don't think that's a direction we should be going down. > > […] > > Oh well :| > > > > […] > > I think that the one, big-scoped compatibility breakage is a feature, not a > bug. At the risk of sounding like a broken record - the C/C++ analogy > works well here too, this time specifically C++. You can evolve the new > language - even substantially - but C++ always stayed C++ and C always > stayed C. Yes, there's C++03, C++11, etc. - but at the end of the day - > the language is C++, and these editions are similar to the evolution we > introduce in feature releases. If your goal is to have major BC breaks > every five years, then I doubt we can find common grounds. But I'm not > sure how many folks here think that's a good idea either. There's a big > gap between thinking we should break away from 20+ year old chains that are > they're fundamentally unhappy about, and moving to a 'let's redo the > language every five years'. > > > > […] > > I'm sorry to hear that. In this particular case I really think you're > wrong (FWIW) - rebranding can actually do a lot of positive things. It can > stir interest. It can result in articles being written. It can make > developers, development leaders and companies who have ruled out PHP > reconsider their decision since "this is no longer PHP". A new version of > PHP, or for that matter a new edition of PHP - will simply not have the > same impact. As much as we're all technical people here, marketing > matters. And in this particular case - this type of positioning does make > sense - as with many of the proposed changes - this really is no longer > PHP. Another thing it can also do is radically simplify the end-user > understanding of our vision of what goes where, and what's in store for PHP > as we currently know it. > > I'm truly hopeful that others on the list (and perhaps you as well) > evaluate this proposal with an open mind. I did run by a few folks (from > the 'other' camp) prior to publishing it, and response was very positive. > > Thanks, > > Zeev --- ## #106468 — Stephen Reay — 2019-08-09T06:52:56+00:00 URL: https://externals.io/message/106453#106468 · In reply to: #106467 > > > Hi Zeev > > Happy to see this proposal pop up, it's good to know that the "other side" is also open for long-term solutions. I think there needs to be a thorough analysis about the pros and cons of the two paths to take: a sister language vs. Nikita's proposal. To me, a userland developer, both solutions would have the same result in the end, so I trust internals to make a well-informed decision. > > There's one thing I haven't seen mentioned yet though: what about the added workload for the core developers? You'll have to maintain two implementations of PHP, be it in the same runtime. Is this a load the core developers are able to carry? Aren't you afraid that development of the "old" version of PHP would quickly decline? If that were to happen, there's little difference in tagging a new major release with the breaking changes/cleanup we want. > > Lastly, how do you envision interop between this two sister languages? Would a "normal" composer package be able to run in P++ ? You did mention P++ would share the same runtime, extensions, etc, but whether the runtime would be able to switch between the old and new version depending on the code wasn't clear to me. > > Kind regards > Brent > > […] As a userland dev (both writing apps and maintaining a library/framework) I’m glad there is discussion about how to move forward, and if I understand his suggestion correctly, Nikita’s approach would be that language features are fundamentally enabled by declare statements as strict_types is now, but that there’d also be “collections” that can be set on, to enable multiple language features at once, AND ideally both single declares and the higher level collections would be able to be set at a level more broad than file based (eg namespace based). I like that this approach gives us a way forward with options for both fine and course grained choices on language features. However I’m also not sure how that particular approach would “solve” the open tags issue that (partly) started this discussion. I guess that whatever sets NS-based declares could define what tag is accepted for later loaded files, but that just moves an ini setting into a declare really. I’ll admit I can’t quite picture how Zeevs proposal would work, and honestly I have concerns it’d turn into a Python2 vs Python3 scenario. It would (seemingly) solve the open tags issue more easily though. Cheers Stephen --- ## #106469 — Joe Watkins — 2019-08-09T07:01:50+00:00 URL: https://externals.io/message/106453#106469 Morning all, First, I want to say that I don't think the polarisation claimed to be occurring is actually occurring. The vast majority of internals voters appear to judge each RFC on it's own merit, while some of them give more weight to retaining bc than others and that effects their vote, they didn't decide how they are going to vote before reading the proposal. There are some very vocal internals mailing list contributors that may give the impression that there is much more dissent, from many more people, or much more controversy than there actually is. A thread is not controversial if some high percentage of the correspondence is from one or two person, it's spammy. When it comes to the proposal being made, that we develop ++ "overnight" and "get everything right the first time" ... I'm not sure how serious these statements are, on their face, they don't make much sense, although they may just be the result of extreme optimism rather than non-thinking. When it comes to the idea of editions, this would appear to have actual merit, there's some overlap with the ++ idea, but they are distinct, and editions and a more forward looking sustainable solution to the problems we are facing and will continue to face. Now I just want to point out the subtle difference between editions, and versions of a language (whatever it's name) ... Should we take up proposal one, and [magically] develop an overnight language, we would have to version subsequent releases as per our versioning guidelines, they would be subject to the same bc concerns that versions of PHP are today. We would find eventually ourselves in exactly the same position with ++ as we are with PHP. Should we take up proposal two, and start to develop opt-in editions to be released alongside minor releases, these editions do not need to have the same BC concerns as regular PHP. Should we make a horrible mistake in some edition, we don't need to take 10 years to fix it, we may even fix it in the very next edition. Cheers Joe > > > […] > not > > […] > not > > […] > > I'd say C++ gives you extra tools to do the job you want to do, and to > do them quicker, and safer (std::string vs char[]). > > > […] > existed > > […] > > I'm not inherently biased against BC. But it doesn't exist in isolation, > in my mind I have to weigh the benefits of BC with the benefits that > breaking BC could bring. IMO, long term, the former is greatly > outweighed by the latter. > > The thing is, I don't see PHP diverging in the way you suggest. I > suspect it would end up being versioned within the same application, > even though I suspect that would be much harder to pull off, it may end > up that it's not actually possible. > > I was trying to think of something which could easily break if passed > between two versions, and something which immediately came to mind was > union types and reflection, a method which returned one string would > need to return an array, or just the first, and so on. > > A "separate" version would certainly be easier. The ability to rip out > everything which wasn't kept would no doubt simplify a lot of things, > but I agree with Nikita's point that it only kicks things down the line > until the next break. > > I think side-by-side engine versions are likely going to be the end > result if it's possible. > > My heart says "clean break" my head says "side by side". > > Mark Randall --- ## #106470 — Zeev Suraski — 2019-08-09T07:15:04+00:00 URL: https://externals.io/message/106453#106470 > > > […] > not > > […] > not > > […] > > I'd say C++ gives you extra tools to do the job you want to do, and to > do them quicker, and safer (std::string vs char[]). > This might be exactly the point. You seem to believe that C++ is inherently superior to C. And it's entirely within your right. However, there are projects - to this date - that prefer C to C++ for a variety of reasons. PHP is one of them, and others include the Linux kernel, redis, nginx, and actually - the vast majority of the fundamental pieces of OS infrastructure our planet runs on. This isn't just for historical reasons - it has to do with a variety of reasons, and the simplicity of C is one of them. In the same way that C developers would resist if someone tried to go on a mission to convert them all to C++ developers - there's a big crowd in the PHP space that would resist some (many) of the things you think are absolutely awesome. The thing is - both of you can be right at the same time - as long as neither side is missionary about their position. > 3. Putting your apparent personal bias against backwards compatibility > > […] > existed > > […] > > I'm not inherently biased against BC. But it doesn't exist in isolation, > in my mind I have to weigh the benefits of BC with the benefits that > breaking BC could bring. We *all* agree. That's the 3rd thing I meant to write and forgot to ("I want to state 3 things and ask another", followed by only 3 items :)). IMO, long term, the former is greatly > outweighed by the latter. > Here we don't all agree. If the benefit is marginal to non-existent - than even when multiplied across decades - it remains marginal to non existent. That's why the position of the more BC-conscious crowd is that each BC break needs to have a good case with tangible benefits. It's always relative - not absolute. The thing is, I don't see PHP diverging in the way you suggest. I > suspect it would end up being versioned within the same application, > even though I suspect that would be much harder to pull off, it may end > up that it's not actually possible. > I'm actually not following what you're saying here, and would appreciate it if you could further explain. But even without entirely understanding what you meant - my guess is that somewhat like C and C++ - these two flavors would cater to different people and different projects. Some frameworks are likely to embrace P++ and declare that their next version is going to be based on that. Others (such as Laravel, apparently) are likely to state they want nothing of it, and would stick with dynamic PHP for the long haul. In turn - end users will also be able to choose whether they stick with PHP for the long haul, keep their PHP investments and start using P++ for their next project, or migrate entirely to P++. All three are viable long term options. And with my approach - you can mix and match the two - so a PHP app can use a P++ framework, a PHP app may expose a P++ plugin API, etc. I was trying to think of something which could easily break if passed > between two versions, and something which immediately came to mind was > union types and reflection, a method which returned one string would > need to return an array, or just the first, and so on. > Passing these types of things across barriers will likely simply not make a lot of sense. It won't be a matter of it breaking - it'll simply not make sense. There'll likely be no issue calling PHP from P++; And PHP code will be exposing APIs using data types that it has, and not ones that it doesn't. Much like C++ developers often call into C (always, in fact, either directly or indirectly)- that's not an issue at all. > A "separate" version would certainly be easier. The ability to rip out > everything which wasn't kept would no doubt simplify a lot of things, > but I agree with Nikita's point that it only kicks things down the line > until the next break. > > I think side-by-side engine versions are likely going to be the end > result if it's possible. > > My heart says "clean break" my head says "side by side". I'm unable to follow that part either. Would appreciate some further elaboration to make it clearer what you have in mind in these three paragraphs... Thanks for the feedback! Zeev --- ## #106471 — Zeev Suraski — 2019-08-09T07:19:54+00:00 URL: https://externals.io/message/106453#106471 · In reply to: #106469 Joe, Top posting on purpose because you seem to focus on the 'overnight' element while not understanding quite what I meant (I'll take the blame for that) - and therefore deriving irrelevant conclusions. When I'm saying "overnight", I mean from the end users' perspective. In the same way that C++ didn't gradually roll out its features as a slow steady stream - but rather, was made available one day with a lot of new capabilities - essentially a new language - that would be the same idea here. It doesn't mean it'll happen on August 10th, at least not 2019. It may take 2 or 3 years to complete. But once we have it ready - it'll be made available in one installment, with all the major issues that are on the top list of folks handled. That is, in contrast to breaking some stuff, and then breaking some more a few years down the line. Zeev > Morning all, > > First, I want to say that I don't think the polarisation claimed to be > occurring is actually occurring. The vast majority of internals voters > appear to judge each RFC on it's own merit, while some of them give more > weight to retaining bc than others and that effects their vote, they didn't > decide how they are going to vote before reading the proposal. There are > some very vocal internals mailing list contributors that may give the > impression that there is much more dissent, from many more people, or much > more controversy than there actually is. A thread is not controversial if > some high percentage of the correspondence is from one or two person, it's > spammy. > > When it comes to the proposal being made, that we develop ++ "overnight" > and "get everything right the first time" ... I'm not sure how serious > these statements are, on their face, they don't make much sense, although > they may just be the result of extreme optimism rather than non-thinking. > > When it comes to the idea of editions, this would appear to have actual > merit, there's some overlap with the ++ idea, but they are distinct, and > editions and a more forward looking sustainable solution to the problems we > are facing and will continue to face. > > Now I just want to point out the subtle difference between editions, and > versions of a language (whatever it's name) ... > > Should we take up proposal one, and [magically] develop an overnight > language, we would have to version subsequent releases as per our > versioning guidelines, they would be subject to the same bc concerns that > versions of PHP are today. We would find eventually ourselves in exactly > the same position with ++ as we are with PHP. > > Should we take up proposal two, and start to develop opt-in editions to be > released alongside minor releases, these editions do not need to have the > same BC concerns as regular PHP. Should we make a horrible mistake in some > edition, we don't need to take 10 years to fix it, we may even fix it in > the very next edition. > > Cheers > Joe > > > > > > > > > > > […] > the > > […] > giving > > […] --- ## #106472 — Nikita Popov — 2019-08-09T07:22:06+00:00 URL: https://externals.io/message/106453#106472 · In reply to: #106457 > > > > > > […] > > 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 > Also - I think that we should do our very best to get this "P++" right the > first time, as opposed to iterate on it and release editions that provide a > steady stream of change and breakage. Of course - we can add new features > and evolve existing ones - but this should be a lot more similar to the > mini versions / feature releases we currently have. > > It's certainly similar in concept, but not quite the same. > > Zeev --- ## #106473 — Kris Craig — 2019-08-09T07:33:04+00:00 URL: https://externals.io/message/106453#106473 · In reply to: #106472 > > > > […] > wrote: > > […] > time > > […] > > 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 --- ## #106474 — Joe Watkins — 2019-08-09T07:38:18+00:00 URL: https://externals.io/message/106453#106474 · In reply to: #106473 *alongside patch Cheers Joe > > > > […] > do > > […] > to > > […] > not > > […] > would > > […] > can > > […] > the > > […] > reasonable > > […] > 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 --- ## #106475 — Sergey Panteleev — 2019-08-09T07:39:53+00:00 URL: https://externals.io/message/106453#106475 · In reply to: #106473 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: sergey@s-panteleev.ru > > > > […] > 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 --- ## #106476 — michal.brzuchalski@gmail.com — 2019-08-09T08:15:25+00:00 URL: https://externals.io/message/106453#106476 · In reply to: #106475 Hi Sergey, pt., 9 sie 2019, 09:40 użytkownik Sergey Panteleev napisał: > 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. > As I understand editions concept it would be far more easy to interoperate with old edition written library than in separate languages like PHP and P++. If new edition introduce syntax breaking change it would be still possible to to interoperate with old code in old edition and work on a project based on new edition. That way you can end up on for eg PHP8 supporting edition=2020 with new features which break compatibility but still working with PHP7.4 treated perhaps by default as edition=2019 in future versions. Cheers, Michał --- ## #106477 — Arvids Godjuks — 2019-08-09T10:25:24+00:00 URL: https://externals.io/message/106453#106477 · In reply to: #106453 чт, 8 авг. 2019 г. в 22:17, Zeev Suraski : > [... and not in the Sith Lord kind of way.] > > *snip* > > Thoughts? > > Zeev > Apparently, this exists: "ezmlm-reject: fatal: Sorry, I don't accept messages larger than 30000 bytes (#5.2.3)", so re-sending with Zeev's part sniped out :) Good day everyone, after literally sleeping on it and stewing for the most part of the morning to gather the thoughts and read other's feedback, here are my 0.02$ as a userland developer who has been on the list for 10+ years :) TL;DR. I think the proposal will not work. C++ worked because it was a completely different time, target audience and environment that does not exist in our day and just plain old lack of a team/resources to pull this behemoth of a feat (but if that would happen successfully, we will have to assign each of the developers an official status of "Wizzard"). The long version: Reason 1: Community and ecosystem. Just look back at how the adoption of 7.1 became to be - if Zeev is saying "overnight" for P++ and means 2-3 years of work, 7.1 was adopted/supported/became the minimum required essentially instantly. I mean it did not take even 6 months for major frameworks, communities and libraries to announce 7.1 support in next major versions or even 7.1 becoming the next minimum required. Some made plans even before 7.1 landed. I mean try updating a project to latest versions of libraries/frameworks today and still stay on 7.0 or 5.6. It is literally impossible because the community has moved on. What my feeling is that either majority will just jump ship to the new P++ or it will get ignored. All that means is that one or the other part will just lack the ecosystem support to survive the transition. I have to say I'm sorry, but today there are just too many alternatives to PHP that work just fine and fragmenting PHP into 2 language branches is just a bad idea. One of the primary reasons PHP did not succumb to winds of popularity and people returning to it for a more sane and stable environment is its ecosystem of robust libraries, tools and framework and people behind them keeping up to date with modern developments. I mean, just look at the 5 to 7 transition in the last 4 years - people dropped BC support like crazy, most of the complaints got "adapt or die" treatment and a lot of people ended up quite happy after doing the upgrades. Many discovered that the problem was a fly rather than an elephant. Tooling was available to automate transitions. Reason 2: Fragmentation, adoption Look at what happened to Hack - that is basically P++ in a nutshell. It got dropped by everyone as soon as PHP 7 got the speed boost and Hack team just saw no more reason to have anything to do with PHP. They also had trouble implementing or supporting parts of PHP functionality. In a sense, I could say the experiment got it's test run and failed. Reason 3: Evolution and resources Maintaining 2 versions of PHP will be daunting, to say the least. In not so distant past PHP core had a lack of resources to even maintain the primary implementation. I really really do not think the PHP core team has the bandwidth to do a P++. And while C is not by any means dying, it's scope of use is somewhat limited in a commercial application these days and it is hard to find jobs, meaning the pool of people who are able to skill up and contribute is small. If anything, I think the majority of people will jump the P++ bandwagon and not pay any attention to the PHP. So a handful of core devs will end up with the responsibility to maintain the PHP core and poor all their available time into it or just give up on it. I know I would jump the bandwagon in that situation without a second thought even if I'm trying to tell myself I'm a more responsible developer. I'm lying to myself :) Reason 4: Suggested features and modes. Going basically statically typed - thanks, but no thanks. There are numerous languages that are statically typed that are suitable for web development and that could and should be used in such an environment is desired. I know people who moved back into PHP because they wanted a more relaxed environment. I think `declare(strict_types=1)` mode got it right and future efforts to enhance that model should be the focus. I mean we ALREADY have 2 versions of PHP going - weak mode and strict mode. What if we just double down on the strict mode? I mean, I just had a wild idea - if a file is included from a "declare(strict_types=1)" scope - do not allow ` 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. It does not need to be a fork. AFAIK there is no technical obstacle to extend lifetime of particular version on PHP and create some kind of LTS line. For example, PHP 7.4 could be supported for 10-20 years (probably with security patches only), so everyone who has "legacy - do not touch it!" code can stick to 7.4 line. Everyone else could just move on and use PHP 8 with all new features and BC breaks. Regards, Robert Korulczyk --- ## #106482 — Mark Randall — 2019-08-09T11:53:51+00:00 URL: https://externals.io/message/106453#106482 · In reply to: #106470 > I'm unable to follow that part either. Would appreciate some further > elaboration to make it clearer what you have in mind in these three > paragraphs... My read of what Nikita was suggesting was some kind of per-file or per-package versioning system that would operate at compile time to add new features at compiler / parser level, and presumably keep them running on the same VM. What I am less sure about is how it would handle BC between versions of the API, the example I gave was reflection and union types. Perhaps I mistook his intention. Mark Randall --- ## #106483 — Zeev Suraski — 2019-08-09T12:07:43+00:00 URL: https://externals.io/message/106453#106483 · In reply to: #106475 On Fri, Aug 9, 2019 at 10:40 AM Sergey Panteleev wrote: > As I understand, in P++ it was planned to drop the legacy code, Correct. > add new functionality Correct. > and painlessly implement BC. > Probably correct - but to phrase it more accurately - when we introduce P++ - we won't be bound by the same level of BC that we're bound by today - simply because migration would be opt in. > Who wants – migrates the PHP project in P++, who doesn't – continues to > use PHP. > Correct. Going forward, things begin to be less correct. P++ isn't "the future of PHP". It's something different, a sister language - that has a different philosophy. It's strongly typed, and has capabilities that many of the folks who want a more advanced/complex language appreciate. New projects, for example, will use P++ already. > Some will, some won't. There'll be plenty of new projects who will be written in PHP. And probably, plenty of new projects written in P++. Well, how is this different from the new version of PHP (e.g. PHP 9)? > It's very, very different. With this approach, even down the line in 2029, PHP remains PHP. None of us has a crystal ball to predict the future, but my guess is that WordPress will stick with PHP, and not move to P++. Based on feedback - Laravel (the most popular PHP framework) - will stick with PHP, and most probably many if not most of the new Laravel-based projects will do the same. If we stick with the current way of doing things, the tension between the strict camp and the dynamic camp (to oversimplify the distinction between them) are going to stay constant or get worse - essentially as many in the strict camp views the dynamic nature of PHP as 'legacy' (you're kind of alluding to that in your question). As much as it doesn't appear to be reflected on internals@ - there are TONS of people out there that like PHP's dynamic nature, and have absolutely no wish to become more and more strict as time passes by. Who wants – adapts his code for PHP 8/9 with all its BCs, who doesn't – > continued to use PHP 7/8. > No, that's not an option for a variety of reasons - for starters, it means that those who are unhappy with the direction the language is going towards, are essentially forced to leave it sooner or later - as they'd get no security updates, no performance improvements, no bugfixes, no new extensions, etc. Also, consider it a given that PHP has to stay a dynamic language. Making it exclusively strict simply isn't an option. Introducing strict while keeping the dynamic ones is an option - but it's a complicated one, and also entails inherent tensions - especially because many in the strict camp view this as a transition, and not an addition. The separation into two 'dialects' can provide a clean way for solving this long term. 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. > I don't think that's relevant, but regardless - we have no data about how many people use short tags. 1% wasn't an estimate, it was just an illustration that even if it's 1% - it's a huge number of people. My guesstimate is that it's a lot more than 1%. > Perhaps the same percentage of users will remain in PHP instead of the > discussed P++. > No, not at all. There are a lot more folks who prefer the dynamic nature of PHP than folks who care about short tags. WordPress developers, Laravel developers - two of the biggest ecosystems in PHP (if not the biggest ones) - seem to generally prefer that. That in itself can easily be several tens of percents of the userbase. > Will the development of a new language be justified due to the few > percentages of users? > The ones who want to develop a new language aren't the ones in the dynamic camp. They're the ones in the strict camp. My proposal allows them to do exactly that, while living in peace with the dynamic camp. Zeev --- Next page: https://externals.io/message/106453.md?page=2