I would very much like to see "editions" or "generations".
> I do plan to create an RFC on this topic. I am looking forward to this Proposal from Nikita. So, at the risk of repeating some ideas that Nikita already mentioned elsewhere, I am sharing my own thoughts.. ## Motivation In this mailing list, it often comes across as if BC support vs "modernizing" the language is a matter of personal preference. The reality is: After a given time, a complex PHP project (whether it be a website or something else) will be a collection of old and new, custom and 3rd party code. The same applies to framework ecosystems, or the entire ecosystem of 3rd party libraries (in composer/packagist and elsewhere). As a (website) project developer: - I want to use the newest tricks of the language, and have the strictest warnings possible, in new custom code. - I want to pick from a wide variety of (old and new) 3rd party libraries. - I don't want to be forced to update or replace legacy 3rd party libraries, that might have been added before I even joined the project, and I have no idea what they do. - I don't want to be forced to fix old legacy custom code, of which I don't know what it does. Or rather, I want to choose when to do this based on the project life cycle. - After phases of active development, I want to be able to put the site in a mode where it "just works", until the client wants a major revamp. - I want the project to run on different local and server environments, possibly sharing the space with other projects. As a library/packge developer: - I want to use the newest tricks of the language, and have the strictest warnings possible, in new code. - I want my library to be compatible with a wide audience with different PHP versions. Existing projects should have the option to include my library without throwing away or revamping all their old stuff. - If developing within a framework ecosystem (e.g. Drupal), I want my library to be compatible with other packages in the same ecosystem, and the PHP version(s) most commonly used within that ecosystem. - After a phase of active development on (a major version of) the package, I want the package (or that major version) to turn into a low-maintenance mode, and focus either on the new major version, or on other things in life. People should be able to use the aging package without major disruption. As a PHP language designer (which I cannot claim to be, but doing it anyway): - I want modern PHP to be a "competitive" language. - At the same time I want PHP to maintain the reputation of being a stable and reliable platform for existing projects. - I want a continuous, incremental evolution of the language, with one change at a time, to allow for sufficient discussion and not lose the community. - I want to allow for future changes which I cannot even dream of today. So I constantly want to "have my cake and eat it, too". Not based on personal preference, but on real-world requirements. ## Proposal / Idea The only way to make this possible is to either deny all progress, or to make a distinction on file level (or "package level", whatever that means). So, opt-in BC breaks. To me the "file level" seems most realistic. If someone can make a convincing point of what "package level" would mean technically, why not. I just think that "package" is not a clearly defined term, and often all you have is a file (e.g. with symlink, or when downloading a file from some place). And sometimes you might want different versions / generations in the same package. This would mean: - A PHP file can specifiy the "generation" or "edition" or simply the version of PHP that it claims to be compatible with. One (perhaps silly) idea would be to have an alternative open tag like "<?php8". I only hope we can come up with a syntax that feels natural and not cryptic. - The PHP installation on a given system could have multiple engines which each have a different compatibility range. This range could be further limited with runtime parameters. - PHP engines with a narrower range might have better performance, because they can be optimized for a specific generation of code compatibility. - Each PHP process (e.g. a web request) might have its own choice of engine and runtime parameters. Perhaps this sounds like a nightmare from a language / engine maintainer perspective - not up to me to judge. -- Andreas On Thu, 8 Aug 2019 at 23:22, Nikita Popov <nikita....@gmail.com> wrote: > > On Thu, Aug 8, 2019 at 11:02 PM Nikita Popov <nikita....@gmail.com> wrote: > > > On Thu, Aug 8, 2019 at 10:17 PM Zeev Suraski <z...@php.net> wrote: > > > >> [... 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/ > > <https://doc.rust-lang.org/edition-guide/editions/index.html> > > edition-guide/editions/index.html > > <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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
