[... 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
[... 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
[... 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 onesat 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
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.
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
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
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.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
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
BrentThis 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.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
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
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
[... 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 onesat 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
On Fri, Aug 30, 2019 at 12:39 PM Andreas Hennings andreas@dqxtech.net
wrote:
I would very much like to see "editions" or "generations".
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.That's not true at all. There are a ton of things that have been discussed
that will progress the language and don't require any sort of BC break.
Union types is one example. Support for Enums is another.
Even if a BC break is required, it's not automatically a bad thing. Whether
we are looking at plugging up a big security hole, getting rid of/modifying
a rarely used feature, adding support for something that it's currently
impossible to do, or just doing something that adds tremendous value to the
language. In all of those cases the impact of the BC break should be
weighed against the benefits.
There have been two proposals recently that have been contentious. Short
tag removal and the current RFC for making undeclared variables throw
errors. In both cases the arguments against these changes were not just a
flat "BC BAD" argument. They all were about the impact of such BC breaks in
comparison to what would be gained. In the case of the undeclared
variables, it's also being argued that we just shouldn't do it because it
gets rid of a feature of the language that some people see as a good
feature. To paint either one of them as an indication that we can't every
do anything that causes a BC break is just flat out false.
I'm not saying what you are proposing here is good or bad. I just wanted to
comment on this particular assertion because I've seen others make such
statements as well, and all they do is cause further division and
animosity. It shifts debate from the merits of a particular issue or RFC to
more abstract levels, where both sides paint the other in absolute terms
that aren't close to valid.
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.
My first reply got rejected by the listserv for being too big. I cleaned up
some the quoted text, but I apologize if anyone sees this twice.
Chase Peeler
chasepeeler@gmail.com
On Fri, Aug 30, 2019 at 12:39 PM Andreas Hennings andreas@dqxtech.net
wrote: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.That's not true at all. There are a ton of things that have been discussed
that will progress the language and don't require any sort of BC break.
Union types is one example. Support for Enums is another.Even if a BC break is required, it's not automatically a bad thing. Whether
we are looking at plugging up a big security hole, getting rid of/modifying
a rarely used feature, adding support for something that it's currently
impossible to do, or just doing something that adds tremendous value to the
language. In all of those cases the impact of the BC break should be
weighed against the benefits.
The problem and trade-offs I am describing are already impacting me today.
I am working on a Drupal 7 site with lots of legacy code, and I am
developing Drupal 7 contrib modules that I want to be available to a
large audience.
In one of these modules I initially used the ?? null coalesce operator.
Then I had to replace all of the instances of ?? with the more verbose
old-school code, to make it compatible with older PHP, because there
are still enough Drupal 7 installations out there which have not
upgraded to PHP 7 yet.
I also had issues with old 3rd party libraries, which stood in the way
of PHP version upgrade.
In a world with "editions" per file or per package, such projects
could more easily use the newest PHP version, while the old libraries
would continue working.
On Fri, Aug 30, 2019 at 12:39 PM Andreas Hennings andreas@dqxtech.net
wrote: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.That's not true at all. There are a ton of things that have been discussed
that will progress the language and don't require any sort of BC break.
Union types is one example. Support for Enums is another.Even if a BC break is required, it's not automatically a bad thing. Whether
we are looking at plugging up a big security hole, getting rid of/modifying
a rarely used feature, adding support for something that it's currently
impossible to do, or just doing something that adds tremendous value to the
language. In all of those cases the impact of the BC break should be
weighed against the benefits.The problem and trade-offs I am describing are already impacting me today.
I am working on a Drupal 7 site with lots of legacy code, and I am
developing Drupal 7 contrib modules that I want to be available to a
large audience.In one of these modules I initially used the ?? null coalesce operator.
Then I had to replace all of the instances of ?? with the more verbose
old-school code, to make it compatible with older PHP, because there
are still enough Drupal 7 installations out there which have not
upgraded to PHP 7 yet.
I also had issues with old 3rd party libraries, which stood in the way
of PHP version upgrade.In a world with "editions" per file or per package, such projects
could more easily use the newest PHP version, while the old libraries
would continue working.
That's a somewhat different issue. Someone running their code on an old and unsupported PHP version is already, well, unsupported. They're running code with known unfixed security issues, most likely, and they take their chances. If they won't upgrade to a supported PHP version then, frankly, they're already on their own.
The point, of course, is making that upgrade as much of a no-brainer as possible so that people have no excuse for not upgrading besides laziness. That's why there's such a (entirely legitimate) concern for BC breaks, because every BC break is one more reason for people to not upgrade to a supported release.
What you're talking about is new language features; well-behaved code written for PHP 5.2 should still run perfectly fine on 7.3, where the ?? operator is quite well supported thank you and if people want to use your new module they should damn well upgrade. (Drupal has had the ability to set a minimum PHP version for a specific module for over a decade; I know, I wrote that functionality. :-) )
I also had issues with old 3rd party libraries, which stood in the way
of PHP version upgrade.
This is the part that is of concern to this discussion. Adding new functionality that doesn't break existing code is entirely irrelevant. It's more around subtle changes to existing behavior, which are sometimes worthwhile and sometimes not.
Whether editions is the "right" way to balance "don't break 1 million lines of 15 year old code" with "this behavior is bad and we all know it" and with "this behavior leads to sloppy code that is prone to bugs", I don't know. I'm not sure what my stance is on these questions yet.
--Larry Garfield
(I hope this exchange is not getting too Drupal-specific.
I imagine the same concerns would apply in any project that uses a lot
of 3rd party code, and that is affected by framework versions and
generations of framework ecosystems.)
Someone running their code on an old and unsupported PHP version is already, well, unsupported.
This is true, but:
- The problem already applies within a range versions that are
officially supported at a given time. E.g. the ?? operator came out
long before PHP 5.6 became unsupported. At the same time, major Drupal
7 modules had to slowly catch up. And some less popular modules never
did. As long as a site was not fully ready for PHP 7.x, developers
could not use the ?? operator, or use any 3rd party code that uses the
?? operator. - There might be reasons preventing people from updating. You already
agree, so nothing to argue here.
The point, of course, is making that upgrade as much of a no-brainer as possible so that people have no excuse for not upgrading besides laziness. That's why there's such a (entirely legitimate) concern for BC breaks, because every BC break is one more reason for people to not upgrade to a supported release.
absolutely.
Adding new functionality that doesn't break existing code is entirely irrelevant. It's more around subtle changes to existing behavior, which are sometimes worthwhile and sometimes not.
These are two sides to the same coin:
- New features which are only available in a new language version.
- Old language "features" (or in most cases "bad practices that used
to be unpunished") which only work in older PHP versions. Of course
this is only a problem if updating or fixing this code would be
costly.
This creates an interoperability problem between old code (if not
fixed or updated) and new code (3rd party or custom), because there is
no engine version that allows them to coexist in the same project.
Realistically, a large project or ecosystem, like a historic building
or a city, will have older and newer parts. Parts you want to touch
and work on, and other parts you rather leave alone.
For unsupported versions we can always say "your fault", but even
within the supported version range there are these interoperability
limitations.
The trade-off on a specific project might be somewhere in the middle:
Use a PHP version that is not the newest but also not the oldest. Fix
or update the worst of the legacy code, but avoid new language
features until the entire system is ready for it.
Of course in the world of technology we cannot expect that a project,
or a framework ecosystem, stays around forever. The language version
is only one variable in the equation. At some point your framework, or
the specific version you are using, will become unsupported.
At some point the entire system needs a rewrite, throwing some old stuff out.
The "editions" idea (or how I imagine it) would not save you from the
need for a periodic rewrite.
But it would allow developers to already use the new language features
and new 3rd party libraries. So they might already write the code that
will later be used in the new rewritten system.
E.g. imagine PHP gets generics one day.
With "editions" (how I imagine them), you could already use generics
in your own custom code, or use composer packages that rely on
generics, in your legacy codebase. If you envision a rewrite that
relies heavily on generics, you can already develop a lot of this code
in the older version of the project.
A project which nowadays would run a PHP version somewhere between the
oldest and the newest, would now be able to run the latest PHP version
most of the time.
On Fri, Aug 30, 2019 at 12:39 PM Andreas Hennings andreas@dqxtech.net
wrote: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.That's not true at all. There are a ton of things that have been discussed
that will progress the language and don't require any sort of BC break.
Union types is one example. Support for Enums is another.Even if a BC break is required, it's not automatically a bad thing. Whether
we are looking at plugging up a big security hole, getting rid of/modifying
a rarely used feature, adding support for something that it's currently
impossible to do, or just doing something that adds tremendous value to the
language. In all of those cases the impact of the BC break should be
weighed against the benefits.The problem and trade-offs I am describing are already impacting me today.
I am working on a Drupal 7 site with lots of legacy code, and I am
developing Drupal 7 contrib modules that I want to be available to a
large audience.In one of these modules I initially used the ?? null coalesce operator.
Then I had to replace all of the instances of ?? with the more verbose
old-school code, to make it compatible with older PHP, because there
are still enough Drupal 7 installations out there which have not
upgraded to PHP 7 yet.
I also had issues with old 3rd party libraries, which stood in the way
of PHP version upgrade.In a world with "editions" per file or per package, such projects
could more easily use the newest PHP version, while the old libraries
would continue working.That's a somewhat different issue. Someone running their code on an old and unsupported PHP version is already, well, unsupported. They're running code with known unfixed security issues, most likely, and they take their chances. If they won't upgrade to a supported PHP version then, frankly, they're already on their own.
The point, of course, is making that upgrade as much of a no-brainer as possible so that people have no excuse for not upgrading besides laziness. That's why there's such a (entirely legitimate) concern for BC breaks, because every BC break is one more reason for people to not upgrade to a supported release.
What you're talking about is new language features; well-behaved code written for PHP 5.2 should still run perfectly fine on 7.3, where the ?? operator is quite well supported thank you and if people want to use your new module they should damn well upgrade. (Drupal has had the ability to set a minimum PHP version for a specific module for over a decade; I know, I wrote that functionality. :-) )
I also had issues with old 3rd party libraries, which stood in the way
of PHP version upgrade.This is the part that is of concern to this discussion. Adding new functionality that doesn't break existing code is entirely irrelevant. It's more around subtle changes to existing behavior, which are sometimes worthwhile and sometimes not.
Whether editions is the "right" way to balance "don't break 1 million lines of 15 year old code" with "this behavior is bad and we all know it" and with "this behavior leads to sloppy code that is prone to bugs", I don't know. I'm not sure what my stance is on these questions yet.
--Larry Garfield
[..]
Whether editions is the "right" way to balance "don't break 1 million lines of 15 year old code" with "this behavior is bad and we all know it" and with "this behavior leads to sloppy code that is prone to bugs", I don't know. I'm not sure what my stance is on these questions yet.
To me the main challenges seem to be to find a syntax that feels
natural, and then the technical feasibility of actually implementing
and maintaining this in the engine.
It probably does feel awkward to have declarations on top of every
file. And it would mean you need to make a conscious choice for every
new file and every new library. Not just a "yes or now", but to pick a
specific version or edition number. You would periodically modify your
code to increase this number.
So doing this on "package level", whatever this means, would have
clear advantages.
To some extent this awkwardness could be seen as the price for having
a language that historically started somewhere very different from
where we would like to see it in the future.
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
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
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
On Fri, Aug 9, 2019 at 12:02 AM Nikita Popov nikita.ppv@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
*alongside patch
Cheers
Joe
On Fri, Aug 9, 2019 at 12:02 AM Nikita Popov nikita.ppv@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
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
On Fri, Aug 9, 2019 at 12:02 AM Nikita Popov nikita.ppv@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
Hi Sergey,
pt., 9 sie 2019, 09:40 użytkownik Sergey Panteleev sergey@s-panteleev.ru
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ł
On Fri, Aug 9, 2019 at 11:15 AM Michał Brzuchalski <
michal.brzuchalski@gmail.com> wrote:
Hi Sergey,
pt., 9 sie 2019, 09:40 użytkownik Sergey Panteleev sergey@s-panteleev.ru
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.
If we intend to break syntax frequently, then yes. But this is poor
language design.
If we take a couple of years to focus on the fundamentals of what folks
find objectionable about PHP today, and introduce P++ with solutions to
these issues - there's no reason that every new version continues to break
compatibility - certainly not in a substantial manner. We need to focus on
the painful changes at the first stage, when P++ is introduced - while
keeping other elements - ones which are incremental but do not introduce
compatibility breaks - to a later time (if we don't have the
developer-power to deliver them).
If we let ourselves off the hook, and do these breakages in stages -
editions are basically a workaround. Yes, editions would allow you to work
around the fact that your code breaks every time you upgrade - but at a
fundamental level, people are still wasting their time writing and
rewriting and then rewriting once more the same code. Not to mention that
unless I'm missing something, maintaining the implementation for all
different editions would be more complicated than having just two dialects.
Now, it doesn't come to say that P++ will never be able to break
compatibility. We also break compatibility in PHP, in major versions. But
it does mean that something along the lines of moving from dynamic to
static, can't happen further down the line. Changing operator or
type-conversion behavior - has to happen now and not further down the
line. Features such as union types and others - can happen at a later
stage. I don't think there's a need for editions for that purpose, the
versions we have are sufficiently granular. Even more so since this will
likely effect P++ more frequently than PHP - a crowd which appears to have
a much stronger bias for features than for downwards compatibility.
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.
I could be wrong, but I don't think that even Nikita thinks we'd have a new
edition every year.
Zeev
Hi Zeev,
pt., 9 sie 2019, 14:23 użytkownik Zeev Suraski zeev@php.net napisał:
On Fri, Aug 9, 2019 at 11:15 AM Michał Brzuchalski <
michal.brzuchalski@gmail.com> wrote:Hi Sergey,
pt., 9 sie 2019, 09:40 użytkownik Sergey Panteleev <sergey@s-panteleev.ru
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.If we intend to break syntax frequently, then yes. But this is poor
language design.
If we take a couple of years to focus on the fundamentals of what folks
find objectionable about PHP today, and introduce P++ with solutions to
these issues - there's no reason that every new version continues to break
compatibility - certainly not in a substantial manner. We need to focus on
the painful changes at the first stage, when P++ is introduced - while
keeping other elements - ones which are incremental but do not introduce
compatibility breaks - to a later time (if we don't have the
developer-power to deliver them).
I've got an impression that you're the only one who sees a good direction
in splitting the language in two different dialects and am not sure about
sincere intentions.
I may be wrong about that but I read this as a way to get evolutionary camp
focus on own dialect and leave PHP in peace. But I think their interests
are in language evolution and not in writing own language.
If we let ourselves off the hook, and do these breakages in stages -
editions are basically a workaround. Yes, editions would allow you to work
around the fact that your code breaks every time you upgrade - but at a
fundamental level, people are still wasting their time writing and
rewriting and then rewriting once more the same code. Not to mention that
unless I'm missing something, maintaining the implementation for all
different editions would be more complicated than having just two dialects.Now, it doesn't come to say that P++ will never be able to break
compatibility. We also break compatibility in PHP, in major versions. But
it does mean that something along the lines of moving from dynamic to
static, can't happen further down the line. Changing operator or
type-conversion behavior - has to happen now and not further down the
line. Features such as union types and others - can happen at a later
stage. I don't think there's a need for editions for that purpose, the
versions we have are sufficiently granular. Even more so since this will
likely effect P++ more frequently than PHP - a crowd which appears to have
a much stronger bias for features than for downwards compatibility.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.I could be wrong, but I don't think that even Nikita thinks we'd have a
new edition every year.
That's just an example.
BR,
Michał
On Fri, Aug 9, 2019 at 3:43 PM Michał Brzuchalski <
michal.brzuchalski@gmail.com> wrote:
I've got an impression that you're the only one who sees a good direction
in splitting the language in two different dialects and am not sure about
sincere intentions.
This isn't splitting the languages, much like TS/JS aren't "split
languages" and C/C++ aren't "split languages". They're sister languages.
For me, sisterhood implies a fairly close relationship.
They would be sharing much of their syntax; They'd be sharing their
runtime, and the developers who develop that runtime; They'd be sharing
their extensions, and the developers who develop them; They'd be sharing
most of their tools.
I may be wrong about that but I read this as a way to get evolutionary
camp focus on own dialect and leave PHP in peace.
If that's the impression I gave, I did a lousy job presenting my idea.
I'm talking about creating P++ as a first-class citizen alongside PHP, on
top of our unified runtime. When you download PHP - you'd be downloading
P++ as well, and vice versa. They'd be versioned and released together.
They'll share bugfixes. They'll share pretty much everything - except for
the deltas in certain syntax elements and behavior.
In a nutshell:
<?php print "hello world!"; ?>
would be PHP, while
<?p++?>
<?php print "hello world!"; ?>
would be P++. That's on the same setup, two-in-one, same binaries (of
course - name/tags/format subject to change, that's just an illustration).
But I think their interests are in language evolution and not in writing
own language.
That languages have to evolve their syntax isn't an axiom. Much if not
most of the evolution in most mature, popular languages happens at the
layers above the language - the standard library, frameworks, apps.
It's not a given that PHP's destiny is to become strictly typed and
introduce more and more BC breaks.
If you go back to my original piece, I'm trying to solve a fundamental
problem that there are two huge camps who have diametrically opposing view
about what needs to happen. It's clear what camp you're on, and that's
absolutely fine - you're among many awesome people. But you need to
realize that there's another huge camp, that thinks very differently than
you about what needs to happen next.
With such opposing views, there are two potential outcomes:
- A zero sum game. A win for one camp is a loss for the other. We've been
mostly in this mode for the last few years. It's not pleasant for anybody. - A creative solution that allows both camps to get what they want.
Zeev
On Fri, Aug 9, 2019 at 10:40 AM Sergey Panteleev sergey@s-panteleev.ru
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
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.
As a simplistic view isn't it just another framework? Haven't the the
likes of WordPress developed their own API on top of PHP and P++ is just
another one? It just has the advantage that it can link deeper into the
core engine than ones which simply sit on top? In exactly the same way
C++ sits on top of C ?
--
Lester Caine
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
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.Kris, Robert,
I'm not sure what you're saying here exactly, but if you are suggesting
that PHP.future, whatever this future version number is - is going to be a
strictly typed language, with total disregard for BC - as folks who want to
go on using and developing for the dynamic version of PHP, and/or want
their existing humongous code bases to go on working - are forced to stick
around with a dead-end version of the language, then no, it is simply not
going to happen, ever.
I think it would be a lousy outcome, but if that's what the "strict camp"
wants, it's going to have to be that camp that forks.
Whether it's a fork or LTS - this is a radical duplication of effort.
The language engine is just one element - extension development, bug fixes,
security fixes - all of these are critically important in order for either
of these projects. If the two diverge - except for the immediate near
term, these efforts would effectively have to happen twice, separately for
each project.
Because I think it's a lousy outcome for everyone - we should (IMHO) take
it off the table, and focus on other outcomes that don't involve forking or
de-facto forking (unlimited-term LTS). I believe my solution gives both
camps virtually all of what they want - with perhaps the lack of indulgence
of some missionary elements in the pro-change/strict/anti-BC camp.
Since the dynamic camp isn't going anywhere, we really have two options -
come to terms that there'll never be a fully strict version of PHP, or
create some sort of mechanism to allow for both. Both Nikita's idea and
mine are a form of the latter, although it seems Nikita's idea does have
a long term goal of moving people - gently and not so gently - towards
strict (over a long period of time). My idea treats both these dialects as
equal among equals - and IMHO, also has some other advantages as far as
clear messaging, market perception and potentially also maintainability.
Zeev
I'm not sure what you're saying here exactly, but if you are suggesting
that PHP.future, whatever this future version number is - is going to be a
strictly typed language, with total disregard for BC /../
I'm suggesting that PHP could stop worrying about "super legacy code which uses short open tags and nobody wants to touch it" and move on. Code that
nobody wants to touch can just use PHP LTS and PHP project could focus on programmers and actively developed projects.
Whether it's a fork or LTS - this is a radical duplication of effort.
Bigger than creating P++ and having two different and competing languages? I highly doubt.
Also, the LTS line could (and probably should) be sponsored. For example, most of BC breaks does not seem to be a problem for OSS. This is mostly a
problem for companies with big and legacy applications, who don't want to spend money on upgrading them. If BC breaks are really such a big problem
for thousands of companies, there should be no problem to find founders to pay ~1 developer for maintaining LTS line and backporting security fixes.
Regards,
Robert Korulczyk
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
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
Hi,
After reading several replies and discussing several solutions, I'd like to
add my feedback to this. Regardless of implementation details, I prefer a
structure similar to the control we have over strict types. I like the idea
of being able to configure this per file, or per "package" (however this
may be implemented). The benefit here is that a certain file, or package,
could run in fancy mode, while (possibly legacy) application code can run
in classic mode. I do assume here that it's primarily behavior changes,
perhaps adding/removing/deprecating functions/classes etc, or throwing
exceptions instead of returning false. I expect that both would be using
the same parser in this scenario.
I'm not exactly sure if this will fix the backwards compatibility concerns
though, at some points BC will have to broken to advance in the classic
mode. Who will decide when a feature should be added in classic mode, or a
behavioral change should be done? One could assume that anything that's not
backwards incompatible could be added without issues. Would that mean that
only "big" BC breaking changes would be added to the fancy version? Would
we be looking at the removal of ==
comparisons in this fancy mode for
example?
Regards,
Lynn van der Berg
[... 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
чт, 8 авг. 2019 г. в 22:17, Zeev Suraski zeev@php.net:
[... 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 <?
usage.
If anything, we can introduce "declare(strict_mode=1)" for all such stuff
(it will include strict_types) and this makes it opt-in and a valid upgrade
path that actually can be done on a per-file basis.
As a userland developer, I don't really want the core concept of PHP to
change. It evolved nicely over time and I actually am on a steady moderate
evolution side of things. If anything, these days a lot more effort should
be put into fixing some of the extensions khm~PDO~khm and maybe working
on some of the async and of course, don't forget the JIT - that will be a
huge focus in next few years and can yield huge benefits to everyone and
everything.
Reason 5: The issue that spawned this thread
What did tick me off about the short tag removal is the fact that there is
an agreement on engine level behaviour switches need to be all removed.
Short tags, as RFC states, is the last one left. I honestly and truly right
now do not care if <?
gets grandfathered in as <?=
did. Though I'm
opposed to leaving <?
, we can make it a permanent parse error if that
makes "code leaks" people happy and leave it there till, idk, PHP10.
What I care about is short_tags = On/Off
switch in php.ini surviving the
purge and resulting in a long term promise that was honoured before this
and now will be broken.
P++ does not solve the original issue regardless.
Reason 6: Extensions and parts of the standard library
At this point, I feel, some attention needs to be redirected at maybe
trying to come up with a cleanup solution for the standard library and
handle the PDO that has been a pain in the ass for everyone to a point
people don't really want to touch it and on the userland side it becoming a
pain to work within certain cases and use workarounds.
I mean really the more I work with databases, the more and more PDO
restrictions, bugs or peculiarities I encounter and less and less I want to
work with it. It is in dire need of either PDOv2 or a different solution.
Closing thoughts:
I feel like both hardcore camps Zeev is describing are too way off base and
want basically impossible. The BC crowd is just being unreasonable and only
the tech that evolves realistically survives. You cannot have the BC cake
and eat it, at some point you have to upgrade and update your application
code. I have migrated personally a 5.2 app straight into late 7.0 release.
I did not find it especially hard and the client found the improved
performance and development speedup worth the spend resources. If anything,
it convinced him to pore resources into a proper rewrite of the system. I
consider PHP to be in a good stot, it just needs a bit more spine in
dropping BC things and because we have BC conscious people in the core, a
lot of the times it is done gracefully and very well. But once a decade or
so something comes up that just cannot technically be handled in a good
way. But people have developed tools that automate the transition, there
are validation tools, code style tools that ALL can detect and warn about
planned upcoming BC break. And plan to actually drop the thing involves "a
5-year plan of gracefull depreciation, errors and final removal". What more
the BC crowd wants to be done then? My view on this is this: "They are
being unreasonable because a plan was made, automation tools were
developed, information is being spread out. People's laziness is not a
valid con argument".
The "upgrade everything, BC be dammed" crowd also needs to chill. If you
are so impatient - there is Go, NodeJS with it's JavaScript/TypeScript,
etc. Right now PHP does has somewhat of a plan and direction it is going,
it is going at a decent pace - not too slow, not too fast. The community is
able to adopt the new features and changes in a timely manner and
gracefully introduce their support or requirement without everyone running
like headless chickens. So maybe solidify the plan, make it into an actual
roadmap? That will allow people to make long term plans and decisions and
make BC less of an issue.
There is also the fact that major parts of PHP that were BC already got
handled and BC breaks since 7.1 have been few and far in between. A few
dangling BC issues that are still present just need a final push and we are
going to end up in a somewhat clean state of things. A lot of future work
is either self-contained new features or can be made opt-in behind a
declare statement.
As I have mentioned, why not expand "declare(strict_types=1)" into a
concept of "declare(strict_mode=1)" and put a lot of upcoming RFC stuff
under it? <?
removal can go into that, so can go the strict operator RFC
and other things that make PHP a more strict language.
Thank you for reading.
Arvīds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius
My goal is to have two sister languages, with both PHP and P++
being equal among equals
PHP internals is already lacking programming resources to do
everything we want to be doing.
Maintaining two versions at once would be more work, so this idea is
not feasible without a dramatic increase in the number of people
working on PHP core.
I think that we should do our very best to get this
"P++" right the first time,
That's a fundamentally bad approach to designing a system. If an
approach is worth doing, it's worth doing even if it's done poorly.
https://www.amazon.co.uk/Systems-Bible-Beginners-Guide-Large/dp/0961825170
cheers
Dan
Ack
My goal is to have two sister languages, with both PHP and P++
being equal among equalsPHP internals is already lacking programming resources to do
everything we want to be doing.Maintaining two versions at once would be more work, so this idea is
not feasible without a dramatic increase in the number of people
working on PHP core.
No, it won't. It will take no additional resources, and in fact, unless
I'm missing something - Nikita's approach would in fact take more resources
in the long run - as we'd have to maintain not just two dialects, but an
open ended number of them.
Much like it's hardly more work for us to maintain both strict and weak
type hints, it shouldn't be significantly more work to maintain both
dialects. The vast majority of work would be the one going into actually
implementing the changed behavior and new features. Since even with
Nikita's idea he's talking about providing a migration path, this is really
not any more work at all. The only valid concern as far as efforts go,
is whether we can pull off the main fundamental changes - the ones which
will likely break any app if we don't introduce them from the get go -
within a reasonable timeframe. I think it can be, but it remains to be
seen.
I think that we should do our very best to get this
"P++" right the first time,
That's a fundamentally bad approach to designing a system.
That's true, but we're not designing a system. We're designing a
language. And to be more accurate - we're redesigning a language, with
ample experience, data and opinions on what we should have done differently.
This is a lot closer to designing an API. And to keep the analogy working
- it's like designing v2 of an API, after you've had a remarkably popular
v1 and collected an endless amount of feedback about both what's good in it
and what's bad. You'd be hard pressed to convince anybody that trying to
get v2 - a version that breaks compatibility significantly and requires
everyone to audit and refactor their code - right from the get go isn't a
good idea that's well worth investing efforts in. Sure, you may not get
around to implementing everything people are asking for - but if you're
forced to break compatibility and are essentially asking people to
partially rewrite their apps - you'd better make sure you do your best so
that you don't have to ask them again a couple of years later down the line.
With language design, it's actually a much bigger deal than with APIs (few
APIs have the level of coupling with someone's code as their programming
language does - hence the cost associated with fixing language-design
mistakes is typically much, much bigger).
Zeev
First of all, Amen to Arvids Godjuks. I think managed to clearly convey the opinion of a majority of the PHP community.
Some small things I like to add. IMHO the backward-incompatible changes that are currently discussed aren't about radical changes, but incremental improvements.
There are a number of issues common in PHP applications, that you don't often find in programs written in other languages. Experienced PHP developers hardly fall for these gotchas, but the quality of PHP applications written by novice developers is typically lower than, for example, written in Python. This is one of the reasons that it's becoming harder and harder to convince people, both within an organization as well as developers in general, to start any new project in PHP. There are issues that are considered unacceptable for a modern language.
Requiring to fork PHP or create a new flavor is unreasonable when compared to other languages. C++ introduced a paradigm shift from a procedural to an object-oriented language. This can't be compared to the changes currently discussed. On the other hand, if we look at changes introduced with major releases in other languages, like Python, Perl, Java, EcmaScript, etc, we can only conclude that even the most progressive portion of the PHP community is still relatively conservative.
Also, the notion that we always had a strong bias for downwards compatibility is not completely accurate. There have been extensive backward-incompatible changes in the past. None of the changes proposed today come even close to the impact that changing the behavior and finally removing register_globals
had.
Using a directive to apply backward-incompatible changes should not be expected to get a lot of support. The limited situation where this would be the case with strict_operators
caused great opposition. The P++ directive proposal would take this, with all the downsides, to a whole nother level.
LTS versions are the tried and tested method to ensure that legacy applications can continue to run. This is favorable to a highly experimental method. Sure LTS requires some extra effort from the maintainers, but not nearly to the same extent that a fork or flavor would.
The real risk to the future of our language isn't related to legacy apps. A bit harsh, but they're vendor locked and will continue to use PHP anyway. On the other hand, this lack of interest in PHP by novice developers is a big problem, as is the diminishing number of new projects that are created in the language. We should prevent PHP from becoming a legacy language.
In short, please just allow PHP to progress in a natural (and slow) pace, rather than forcing a fork which has changed to much that switching is not trivial and on the other side have an original that completely stagnant.
Yours,
Arnold
Arnold Daniels - Chat @ Spike [3yfvn]
Hello,
[... 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
From my understanding the core thought and philosophy here is very
great. Also thank you that we even have such discussion. It shows that
PHP cares for future changes after all. Maybe instead of making two
languages there probably is also some kind of other middle way (like
it was mentioned in one of your emails in the past I think a bit):
Something such as "legacy" extension (or better named to not cause
issues with meaning that something like short tags will go away in
future - the "traditional" extension) or something like that.
Where developer would have option to enable it and use "traditional"
or whatever named PHP functionalities such as short tags and things
that cause so many issues and being sidelines. Without enabling (or
importing that), PHP would behave more futuristic oriented.
There will still be a need to take compromises in either case. Even in
the PHP vs PHP++ case where people will want to change something in
the PHP or do differently in PHP++. That's quite normal. Important
thing is that everyone has a bit of an overview of everyone else also.
One camp that recommends going without short tags and the other that
wants these in, as an example.
--
Peter Kokot