Re: [PHP-DEV] Bringing Peace to the Galaxy

[Andreas Hennings]

On Sat, 31 Aug 2019 at 02:31, Larry Garfield  wrote:
> [..]
> 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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Andreas Hennings]

Some clarifications before I get crucified:


> "editions" (the way I imagine)

I don't want to misrepresent Nikita. His idea of editions might be
completely different.


> If "editions" (the way I imagine) had been introduced prior to PHP 7, we 
> might now have a PHP 7 engine that would still support code written for PHP 
> 5.x.

Of course in general, most of the code "written for PHP 5.x" already
works in PHP 7. Except when it doesn't.

But the argument goes further.
If "editions" had been around earlier, perhaps the opt-in flavor of
PHP 7.n would already be more strict than it the non-opt-in flavor of
PHP 7.n is now.
Having the possibility to let files opt-in can allow for bolder and
faster innovation, with less holding back.


On Sat, 31 Aug 2019 at 03:52, Andreas Hennings  wrote:
>
> On Sat, 31 Aug 2019 at 03:40, Reindl Harald  wrote:
> >
> >
> >
> > Am 30.08.19 um 20:56 schrieb Andreas Hennings:
> > > 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.
> >
> > no, it could not, when these days installations aren't running PHP7 at
> > all you won#t have support for new features
>
> If "editions" (the way I imagine) had been introduced prior to PHP 7,
> we might now have a PHP 7 engine that would still support code written
> for PHP 5.x.
>
> There is a limit in how far this makes sense. In a lot of cases, what
> "breaks" in PHP7 was already broken to begin with.
> So in a way the BC breaks can be a good thing, they force people to
> fix the mistakes from the past.
>
> >
> > you can declare what you want on top of the file - when the server is
> > sloppy mainatined and running stone old software you simply can't use a
> > recent feature
> >
> > just stop supporting such unmaintained setups and they will disappear,
> > break them as hard as you can!
> >
> you need to distinguish two different things here:
> - server infrastructure / php version.
> - the actual PHP code in the project, which might be a collection of
> custom code and various 3rd party packages with different age.
>
> upgrading the server infrastructure and php version is easy, compared
> to upgrading or fixing the PHP code itself.
> The only reason why people might stick with an old infrastructure and
> php version is because the new version might break their legacy PHP
> code.
>
> As said earlier, I would claim that increased BC tolerance with opt-in
> strictness per file would make it more likely that people use the
> latest php version available.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Andreas Hennings]

On Sat, 31 Aug 2019 at 03:40, Reindl Harald  wrote:
>
>
>
> Am 30.08.19 um 20:56 schrieb Andreas Hennings:
> > 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.
>
> no, it could not, when these days installations aren't running PHP7 at
> all you won#t have support for new features

If "editions" (the way I imagine) had been introduced prior to PHP 7,
we might now have a PHP 7 engine that would still support code written
for PHP 5.x.

There is a limit in how far this makes sense. In a lot of cases, what
"breaks" in PHP7 was already broken to begin with.
So in a way the BC breaks can be a good thing, they force people to
fix the mistakes from the past.

>
> you can declare what you want on top of the file - when the server is
> sloppy mainatined and running stone old software you simply can't use a
> recent feature
>
> just stop supporting such unmaintained setups and they will disappear,
> break them as hard as you can!
>
you need to distinguish two different things here:
- server infrastructure / php version.
- the actual PHP code in the project, which might be a collection of
custom code and various 3rd party packages with different age.

upgrading the server infrastructure and php version is easy, compared
to upgrading or fixing the PHP code itself.
The only reason why people might stick with an old infrastructure and
php version is because the new version might break their legacy PHP
code.

As said earlier, I would claim that increased BC tolerance with opt-in
strictness per file would make it more likely that people use the
latest php version available.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Andreas Hennings]

(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 Sat, 31 Aug 2019 at 02:31, Larry Garfield  wrote:
>
> On Fri, Aug 30, 2019, at 1:56 PM, Andreas Hennings wrote:
> > On Fri, 30 Aug 2019 at 19:38, Chase Peeler  wrote:
> > > On Fri, Aug 30, 2019 at 12:39 PM Andreas Hennings 
> > > 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 

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Larry Garfield]

On Fri, Aug 30, 2019, at 1:56 PM, Andreas Hennings wrote:
> On Fri, 30 Aug 2019 at 19:38, Chase Peeler  wrote:
> > On Fri, Aug 30, 2019 at 12:39 PM Andreas Hennings 
> > 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Andreas Hennings]

On Fri, 30 Aug 2019 at 19:38, Chase Peeler  wrote:
> On Fri, Aug 30, 2019 at 12:39 PM Andreas Hennings 
> 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.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Chase Peeler]

On Fri, Aug 30, 2019 at 12:39 PM Andreas Hennings 
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
chasepee...@gmail.com

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Andreas Hennings]

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 " wrote:
>
> On Thu, Aug 8, 2019 at 11:02 PM Nikita Popov  wrote:
>
> > On Thu, Aug 8, 2019 at 10:17 PM Zeev Suraski  wrote:
> >
> >> [... and not in the Sith Lord kind of way.]
> >>
> >> Looking at some of the recent (& not so recent) discussions on internals@
> >> ,
> >> some of the recent proposals, as well as some of the statements made
> >> regarding the future direction of the language - makes it fairly clear
> >> that
> >> we have a growing sense of polarization.
> >>
> >> As Peter put it yesterday (I may be paraphrasing a bit) - some folks just
> >> want to clear some legacy stuff.  I think that in practice it goes well
> >> beyond that - many on internals@ see parts of PHP as in bad need of
> >> repair
> >> (scoop: I agree with some of that), while other capabilities, that exist
> >> in
> >> other competing languages - are - in their opinion - sorely missing.
> >>
> >> At the other end of the spectrum, we have folks who think that we should
> >> retain the strong bias for downwards compatibility we always had, that PHP
> >> isn't in dire need of an overhauling repair and that as far as features go
> >> - less is more - and we don't have to race to replicate features from
> >> other
> >> languages - 

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Lynn]

On Thu, Aug 8, 2019 at 11:02 PM Nikita Popov  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 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

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Peter Kokot]

Hello,

On Thu, 8 Aug 2019 at 22:17, Zeev Suraski  wrote:
>
> [... and not in the Sith Lord kind of way.]
>
> Looking at some of the recent (& not so recent) discussions on internals@,
> some of the recent proposals, as well as some of the statements made
> regarding the future direction of the language - makes it fairly clear that
> we have a growing sense of polarization.
>
> As Peter put it yesterday (I may be paraphrasing a bit) - some folks just
> want to clear some legacy stuff.  I think that in practice it goes well
> beyond that - many on internals@ see parts of PHP as in bad need of repair
> (scoop: I agree with some of that), while other capabilities, that exist in
> other competing languages - are - in their opinion - sorely missing.
>
> At the other end of the spectrum, we have folks who think that we should
> retain the strong bias for downwards compatibility we always had, that PHP
> isn't in dire need of an overhauling repair and that as far as features go
> - less is more - and we don't have to race to replicate features from other
> languages - but rather opt for keeping PHP simple.
>
> To a large degree, these views are diametrically opposed.  This made many
> internals@ discussions turn into literally zero sum games - where when one
> side 'wins', the other side 'loses', and vice versa.
>
> It's fair to say that I'm a lot closer in the way I view things to the
> latter camp that the former one.  But, at the same time - I understand that
> there's merit to the other POV.  Even when my POV 'wins', it often feels as
> a bit of a Pyrrhic victory, as the negative vibes from these zero sum
> discussions and the feeling of disappointment felt by folks in the other
> group - many of which I have very high respect for - are definitely not
> good for the project (I hope that at least some of them feel in the same
> way when things happen in reverse).
>
> Now, what if there was a way to truly make both 'camps' happy?  I think
> there may be.
>
> There are several successful examples for how languages evolved
> dramatically while doing exactly that - retaining downwards compatibility
> while introducing radical changes - including compatibility breaking ones -
> at the same time.
>
> The most obvious example that comes to mind if C++.  It's a whole new
> language, that clearly borrows a much of its basic syntax from C, but also
> adds many fundamental new features on top of it - and changes behavior in
> many situations.  When I say that C++ is compatible with C - it's not that
> you can run (or compile) any given piece of C code on C++ - you definitely
> cannot - but you can call C code from C++ code fairly transparently, and
> you wouldn't have to change anything at all in your C code.  If you have a
> piece of code written in C and you don't care about C++ - you don't have to
> do anything at all.  In the same way, if you're a C developer, and don't
> care much for C++ - you're not forced to learn it - as long as you work on
> C-based projects.  That will never change.
>
> Another somewhat similar example is ES6 - where a lot of new capabilities
> are added without breaking anything about the underlying ES5.
>
> By now I think the idea should be obvious - what if we did something
> similar for PHP?
>
> Essentially - radically slow down the amount of language-level (read:
> syntax) changes - both additions, deprecations and modifications in PHP
> itself;  But, simultaneously - make the engine understand a new flavor of
> the language (phure?  phun?  phlex?  phuture?) - a flavor where we'd in
> fact be able to introduce a wide range of changes overnight - a lot more
> rapidly than even folks in the former camp feel comfortable doing today.
> Since the vast majority of contention between the two camps has to do with
> either downwards compatibility or 'language fit' - introducing a new flavor
> of the language, which is available in addition to the current one instead
> of replacing it - can provide a fundamental solution to both of these
> points of contention.
>
> We actually have a substantial advantage over both of the above-mentioned
> language sets (C/C++ and JS/ES6) as for all practical purposes - we control
> the single relevant implementation of the language.  At this point - I also
> see no reason of why that implementation wouldn't be able to handle both
> flavors of the language - sharing the same compiler and runtime - and
> allowing them to run simultaneously alongside each other, in a similar way
> that C++ code can run and interoperate with C code at runtime, despite
> being substantially different languages.  The runtime will simply know how
> to run in two different modes - depending on the file at hand - similarly
> to how we do strict types (and we could probably entertain other options as
> well, like doing it on a namespace level).
>
> I want to illustrate what I think this will buy us, at least from my POV.
>
> In P++ (temp code name) - we'd be able to get rid of elements 

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Arnold Daniels]

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](https://www.spikenow.com/?ref=spike-organic-signature&_ts=3yfvn)
[3yfvn]

On August 9, 2019 at 13:41 GMT, Zeev Suraski  wrote:

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Zeev Suraski]

On Fri, Aug 9, 2019 at 4:12 PM Dan Ackroyd  wrote:

> On Thu, 8 Aug 2019 at 21:17, Zeev Suraski  wrote:
> >
> > 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.
>

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 *re*designing 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

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Zeev Suraski]

On Fri, Aug 9, 2019 at 10:22 AM Nikita Popov  wrote:

> On Thu, Aug 8, 2019 at 11:25 PM Zeev Suraski  wrote:
>
> I think this part is unrealistic from a simple manpower perspective. We
> have something like ~2 full time developers working on PHP. Even if you can
> rally some additional interest around this idea, I don't think we have the
> resources to create a *substantially* different language in any reasonable
> amount of time. Doing feature additions and changes to PHP is Hard. Even
> simple changes require a fair bit of design and engineering effort to
> integrate with the large complexity of the existing language. This would
> not change for a hypothetical P++, because we still need to interoperate
> with PHP.
>

I think we should focus on the changes, and have additions as 2nd
priority.  We'll likely to get to some additions, just not all - it's fine
to add them at a later stage, like the following mini version.

Regardless of which direction we go for, it will probably be a good idea
for us to pause for a moment and think about what are the major issues we'd
want to address in PHP.  I don't think the list of *changes* is that long
that we can't pull off at least the majority of it in 2 years.  Factor in
the fact that instead of having heated discussions on internals@ and beyond
- about language fit and BC - we'd be able to focus exclusively on the best
solution for the problem - in the eyes of the folks in the 'strict' camp.


> Even if I agreed with the idea (which I'm pretty skeptical about in this
> particular form), I really don't think we have the resources to do
> something like this.


That may be, but I don't think that's the case.  Perhaps it would help if
we started a wiki page with topics that we'd want to address in such a
hypothetical project.  Strict ops, changes to type conversions, array
indices, variable declarations, etc.  I don't know that the list is *that*
 long.

Even if we go for your 'edition' approach (which by the way, isn't entirely
mutually exclusive from my idea - we could have these editions for P++ if
we thought it made sense) - our users would be a lot better served if we
handled the major BC breaks at first, as opposed to providing them in a
steady flow of breakage.  It would be a pretty lousy outcome if
PHP2020-native frameworks and apps became fundamentally broken when
upgrading to PHP2024.

Zeev

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Zeev Suraski]

On Fri, Aug 9, 2019 at 3:43 PM Michał Brzuchalski <
michal.brzuchal...@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:

would be PHP, while



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

>

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Dan Ackroyd]

On Thu, 8 Aug 2019 at 21:17, Zeev Suraski  wrote:
>
> 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Robert Korulczyk]

> 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Michał Brzuchalski]

Hi Zeev,

pt., 9 sie 2019, 14:23 użytkownik Zeev Suraski  napisał:

>
>
> On Fri, Aug 9, 2019 at 11:15 AM Michał Brzuchalski <
> michal.brzuchal...@gmail.com> wrote:
>
>> Hi Sergey,
>>
>> pt., 9 sie 2019, 09:40 użytkownik Sergey Panteleev > >
>> napisał:
>>
>> > As I understand, in P++ it was planned to drop the legacy code, add new
>> > functionality and painlessly implement BC.
>> >
>> > Who wants – migrates the PHP project in P++, who doesn't – continues to
>> > use PHP.
>> >
>> > New projects, for example, will use P++ already.
>> >
>> > Well, how is this different from the new version of PHP (e.g. PHP 9)?
>> >
>> > Who wants – adapts his code for PHP 8/9 with all its BCs, who doesn't –
>> > continued to use PHP 7/8.
>> >
>>
>> As I understand editions concept it would be far more easy to interoperate
>> with old edition written library than in separate languages like PHP and
>> P++. If new edition introduce syntax breaking change it would be still
>> possible to to interoperate with old code in old edition and work on a
>> project based on new edition.
>>
>
> 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ł

>

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Zeev Suraski]

On Fri, Aug 9, 2019 at 1:44 PM Robert Korulczyk  wrote:

> > 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

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Lester Caine]

On 09/08/2019 13:07, Zeev Suraski wrote:

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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Zeev Suraski]

On Fri, Aug 9, 2019 at 11:15 AM Michał Brzuchalski <
michal.brzuchal...@gmail.com> wrote:

> Hi Sergey,
>
> pt., 9 sie 2019, 09:40 użytkownik Sergey Panteleev 
> napisał:
>
> > As I understand, in P++ it was planned to drop the legacy code, add new
> > functionality and painlessly implement BC.
> >
> > Who wants – migrates the PHP project in P++, who doesn't – continues to
> > use PHP.
> >
> > New projects, for example, will use P++ already.
> >
> > Well, how is this different from the new version of PHP (e.g. PHP 9)?
> >
> > Who wants – adapts his code for PHP 8/9 with all its BCs, who doesn't –
> > continued to use PHP 7/8.
> >
>
> As I understand editions concept it would be far more easy to interoperate
> with old edition written library than in separate languages like PHP and
> P++. If new edition introduce syntax breaking change it would be still
> possible to to interoperate with old code in old edition and work on a
> project based on new edition.
>

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

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Zeev Suraski]

On Fri, Aug 9, 2019 at 10:40 AM Sergey Panteleev 
wrote:

> As I understand, in P++ it was planned to drop the legacy code,


Correct.


> add new functionality


Correct.

> and painlessly implement BC.
>

Probably correct - but to phrase it more accurately - when we introduce P++
- we won't be bound by the same level of BC that we're bound by today -
simply because migration would be opt in.


> Who wants – migrates the PHP project in P++, who doesn't – continues to
> use PHP.
>

Correct.

Going forward, things begin to be less correct.  P++ isn't "the future of
PHP".  It's something different, a sister language - that has a different
philosophy.  It's strongly typed, and has capabilities that many of the
folks who want a more advanced/complex language appreciate.

New projects, for example, will use P++ already.
>

Some will, some won't.  There'll be plenty of new projects who will be
written in PHP.  And probably, plenty of new projects written in P++.

Well, how is this different from the new version of PHP (e.g. PHP 9)?
>

It's very, very different.

With this approach, even down the line in 2029, PHP remains PHP.  None of
us has a crystal ball to predict the future, but my guess is that WordPress
will stick with PHP, and not move to P++.  Based on feedback - Laravel (the
most popular PHP framework) - will stick with PHP, and most probably many
if not most of the new Laravel-based projects will do the same.

If we stick with the current way of doing things, the tension between the
strict camp and the dynamic camp (to oversimplify the distinction between
them) are going to stay constant or get worse - essentially as many in the
strict camp views the dynamic nature of PHP as 'legacy' (you're kind of
alluding to that in your question).  As much as it doesn't appear to be
reflected on internals@ - there are TONS of people out there that like
PHP's dynamic nature, and have absolutely no wish to become more and more
strict as time passes by.

Who wants – adapts his code for PHP 8/9 with all its BCs, who doesn't –
> continued to use PHP 7/8.
>

No, that's not an option for a variety of reasons - for starters, it means
that those who are unhappy with the direction the language is going
towards, are essentially forced to leave it sooner or later - as they'd get
no security updates, no performance improvements, no bugfixes, no new
extensions, etc.  Also, consider it a given that PHP has to stay a dynamic
language.  Making it exclusively strict simply isn't an option.
Introducing strict while keeping the dynamic ones is an option - but it's a
complicated one, and also entails inherent tensions - especially because
many in the strict camp view this as a transition, and not an addition.
The separation into two 'dialects' can provide a clean way for solving this
long term.

Because this discussion flows smoothly from a neighboring branch, let me
> remind you that a few percentages of users who continue to use short tags
> were discussed there.
>

I don't think that's relevant, but regardless - we have no data about how
many people use short tags.  1% wasn't an estimate, it was just an
illustration that even if it's 1% - it's a huge number of people.  My
guesstimate is that it's a lot more than 1%.


> Perhaps the same percentage of users will remain in PHP instead of the
> discussed P++.
>

No, not at all.  There are a lot more folks who prefer the dynamic nature
of PHP than folks who care about short tags.  WordPress developers, Laravel
developers - two of the biggest ecosystems in PHP (if not the biggest ones)
- seem to generally prefer that.  That in itself can easily be several tens
of percents of the userbase.


> Will the development of a new language be justified due to the few
> percentages of users?
>

The ones who want to develop a new language aren't the ones in the dynamic
camp.  They're the ones in the strict camp.
My proposal allows them to do exactly that, while living in peace with the
dynamic camp.

Zeev

Re: [PHP-DEV] Bringing Peace to the Galaxy

[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.


Regards,
Robert Korulczyk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Arvids Godjuks]

чт, 8 авг. 2019 г. в 22:17, Zeev Suraski :

> [... and not in the Sith Lord kind of way.]
>
> *snip*
>
> Thoughts?
>
> Zeev
>

Apparently, this exists: "ezmlm-reject: fatal: Sorry, I don't accept
messages larger than 3 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 `https://t.me/psihius

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Michał Brzuchalski]

Hi Sergey,

pt., 9 sie 2019, 09:40 użytkownik Sergey Panteleev 
napisał:

> As I understand, in P++ it was planned to drop the legacy code, add new
> functionality and painlessly implement BC.
>
> Who wants – migrates the PHP project in P++, who doesn't – continues to
> use PHP.
>
> New projects, for example, will use P++ already.
>
> Well, how is this different from the new version of PHP (e.g. PHP 9)?
>
> Who wants – adapts his code for PHP 8/9 with all its BCs, who doesn't –
> continued to use PHP 7/8.
>

As I understand editions concept it would be far more easy to interoperate
with old edition written library than in separate languages like PHP and
P++. If new edition introduce syntax breaking change it would be still
possible to to interoperate with old code in old edition and work on a
project based on new edition.

That way you can end up on for eg PHP8 supporting edition=2020 with new
features which break compatibility but still working with PHP7.4 treated
perhaps by default as edition=2019 in future versions.

Cheers,
Michał

>

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Sergey Panteleev]

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: ser...@s-panteleev.ru
On 9 Aug 2019, 10:33 +0300, Kris Craig , wrote:
> On Fri, Aug 9, 2019 at 12:22 AM Nikita Popov  wrote:
>
> > On Thu, Aug 8, 2019 at 11:25 PM Zeev Suraski  wrote:
> >
> > >
> > >
> > > On Fri, Aug 9, 2019 at 12:02 AM Nikita Popov 
> > 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

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Joe Watkins]

*alongside patch

Cheers
Joe

On Fri, 9 Aug 2019, 09:33 Kris Craig,  wrote:

> On Fri, Aug 9, 2019 at 12:22 AM Nikita Popov  wrote:
>
> > On Thu, Aug 8, 2019 at 11:25 PM Zeev Suraski  wrote:
> >
> > >
> > >
> > > On Fri, Aug 9, 2019 at 12:02 AM Nikita Popov 
> > 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
>

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Kris Craig]

On Fri, Aug 9, 2019 at 12:22 AM Nikita Popov  wrote:

> On Thu, Aug 8, 2019 at 11:25 PM Zeev Suraski  wrote:
>
> >
> >
> > On Fri, Aug 9, 2019 at 12:02 AM Nikita Popov 
> 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

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Nikita Popov]

On Thu, Aug 8, 2019 at 11:25 PM Zeev Suraski  wrote:

>
>
> On Fri, Aug 9, 2019 at 12:02 AM Nikita Popov  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



> 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
>
>
>

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Stephen Reay]

> On 9 Aug 2019, at 12:11, Brent  wrote:
> 
> 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
>> On 8 Aug 2019, 23:59 +0200, Zeev Suraski , wrote:
>>> On Fri, Aug 9, 2019 at 12:22 AM Nikita Popov  wrote:
>>> 
 On Thu, Aug 8, 2019 at 11:02 PM Nikita Popov  wrote:
 
 On Thu, Aug 8, 2019 at 10:17 PM Zeev Suraski  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 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
>> 

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Brent]

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
On 8 Aug 2019, 23:59 +0200, Zeev Suraski , wrote:
> On Fri, Aug 9, 2019 at 12:22 AM Nikita Popov  wrote:
>
> > On Thu, Aug 8, 2019 at 11:02 PM Nikita Popov  wrote:
> >
> > > On Thu, Aug 8, 2019 at 10:17 PM Zeev Suraski  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 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 

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Zeev Suraski]

On Fri, Aug 9, 2019 at 12:22 AM Nikita Popov  wrote:

> On Thu, Aug 8, 2019 at 11:02 PM Nikita Popov  wrote:
>
>> On Thu, Aug 8, 2019 at 10:17 PM Zeev Suraski  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 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 

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Zeev Suraski]

On Fri, Aug 9, 2019 at 12:02 AM Nikita Popov  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++.

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

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Nikita Popov]

On Thu, Aug 8, 2019 at 11:02 PM Nikita Popov  wrote:

> On Thu, Aug 8, 2019 at 10:17 PM Zeev Suraski  wrote:
>
>> [... and not in the Sith Lord kind of way.]
>>
>> Looking at some of the recent (& not so recent) discussions on internals@
>> ,
>> some of the recent proposals, as well as some of the statements made
>> regarding the future direction of the language - makes it fairly clear
>> that
>> we have a growing sense of polarization.
>>
>> As Peter put it yesterday (I may be paraphrasing a bit) - some folks just
>> want to clear some legacy stuff.  I think that in practice it goes well
>> beyond that - many on internals@ see parts of PHP as in bad need of
>> repair
>> (scoop: I agree with some of that), while other capabilities, that exist
>> in
>> other competing languages - are - in their opinion - sorely missing.
>>
>> At the other end of the spectrum, we have folks who think that we should
>> retain the strong bias for downwards compatibility we always had, that PHP
>> isn't in dire need of an overhauling repair and that as far as features go
>> - less is more - and we don't have to race to replicate features from
>> other
>> languages - but rather opt for keeping PHP simple.
>>
>> To a large degree, these views are diametrically opposed.  This made many
>> internals@ discussions turn into literally zero sum games - where when
>> one
>> side 'wins', the other side 'loses', and vice versa.
>>
>> It's fair to say that I'm a lot closer in the way I view things to the
>> latter camp that the former one.  But, at the same time - I understand
>> that
>> there's merit to the other POV.  Even when my POV 'wins', it often feels
>> as
>> a bit of a Pyrrhic victory, as the negative vibes from these zero sum
>> discussions and the feeling of disappointment felt by folks in the other
>> group - many of which I have very high respect for - are definitely not
>> good for the project (I hope that at least some of them feel in the same
>> way when things happen in reverse).
>>
>> Now, what if there was a way to truly make both 'camps' happy?  I think
>> there may be.
>>
>> There are several successful examples for how languages evolved
>> dramatically while doing exactly that - retaining downwards compatibility
>> while introducing radical changes - including compatibility breaking ones
>> -
>> at the same time.
>>
>> The most obvious example that comes to mind if C++.  It's a whole new
>> language, that clearly borrows a much of its basic syntax from C, but also
>> adds many fundamental new features on top of it - and changes behavior in
>> many situations.  When I say that C++ is compatible with C - it's not that
>> you can run (or compile) any given piece of C code on C++ - you definitely
>> cannot - but you can call C code from C++ code fairly transparently, and
>> you wouldn't have to change anything at all in your C code.  If you have a
>> piece of code written in C and you don't care about C++ - you don't have
>> to
>> do anything at all.  In the same way, if you're a C developer, and don't
>> care much for C++ - you're not forced to learn it - as long as you work on
>> C-based projects.  That will never change.
>>
>> Another somewhat similar example is ES6 - where a lot of new capabilities
>> are added without breaking anything about the underlying ES5.
>>
>> By now I think the idea should be obvious - what if we did something
>> similar for PHP?
>>
>> Essentially - radically slow down the amount of language-level (read:
>> syntax) changes - both additions, deprecations and modifications in PHP
>> itself;  But, simultaneously - make the engine understand a new flavor of
>> the language (phure?  phun?  phlex?  phuture?) - a flavor where we'd in
>> fact be able to introduce a wide range of changes overnight - a lot more
>> rapidly than even folks in the former camp feel comfortable doing today.
>> Since the vast majority of contention between the two camps has to do with
>> either downwards compatibility or 'language fit' - introducing a new
>> flavor
>> of the language, which is available in addition to the current one instead
>> of replacing it - can provide a fundamental solution to both of these
>> points of contention.
>>
>> We actually have a substantial advantage over both of the above-mentioned
>> language sets (C/C++ and JS/ES6) as for all practical purposes - we
>> control
>> the single relevant implementation of the language.  At this point - I
>> also
>> see no reason of why that implementation wouldn't be able to handle both
>> flavors of the language - sharing the same compiler and runtime - and
>> allowing them to run simultaneously alongside each other, in a similar way
>> that C++ code can run and interoperate with C code at runtime, despite
>> being substantially different languages.  The runtime will simply know how
>> to run in two different modes - depending on the file at hand - similarly
>> to how we do strict types (and we could probably entertain other options
>> as
>> well, like 

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Nikita Popov]

On Thu, Aug 8, 2019 at 10:17 PM Zeev Suraski  wrote:

> [... and not in the Sith Lord kind of way.]
>
> Looking at some of the recent (& not so recent) discussions on internals@,
> some of the recent proposals, as well as some of the statements made
> regarding the future direction of the language - makes it fairly clear that
> we have a growing sense of polarization.
>
> As Peter put it yesterday (I may be paraphrasing a bit) - some folks just
> want to clear some legacy stuff.  I think that in practice it goes well
> beyond that - many on internals@ see parts of PHP as in bad need of repair
> (scoop: I agree with some of that), while other capabilities, that exist in
> other competing languages - are - in their opinion - sorely missing.
>
> At the other end of the spectrum, we have folks who think that we should
> retain the strong bias for downwards compatibility we always had, that PHP
> isn't in dire need of an overhauling repair and that as far as features go
> - less is more - and we don't have to race to replicate features from other
> languages - but rather opt for keeping PHP simple.
>
> To a large degree, these views are diametrically opposed.  This made many
> internals@ discussions turn into literally zero sum games - where when one
> side 'wins', the other side 'loses', and vice versa.
>
> It's fair to say that I'm a lot closer in the way I view things to the
> latter camp that the former one.  But, at the same time - I understand that
> there's merit to the other POV.  Even when my POV 'wins', it often feels as
> a bit of a Pyrrhic victory, as the negative vibes from these zero sum
> discussions and the feeling of disappointment felt by folks in the other
> group - many of which I have very high respect for - are definitely not
> good for the project (I hope that at least some of them feel in the same
> way when things happen in reverse).
>
> Now, what if there was a way to truly make both 'camps' happy?  I think
> there may be.
>
> There are several successful examples for how languages evolved
> dramatically while doing exactly that - retaining downwards compatibility
> while introducing radical changes - including compatibility breaking ones -
> at the same time.
>
> The most obvious example that comes to mind if C++.  It's a whole new
> language, that clearly borrows a much of its basic syntax from C, but also
> adds many fundamental new features on top of it - and changes behavior in
> many situations.  When I say that C++ is compatible with C - it's not that
> you can run (or compile) any given piece of C code on C++ - you definitely
> cannot - but you can call C code from C++ code fairly transparently, and
> you wouldn't have to change anything at all in your C code.  If you have a
> piece of code written in C and you don't care about C++ - you don't have to
> do anything at all.  In the same way, if you're a C developer, and don't
> care much for C++ - you're not forced to learn it - as long as you work on
> C-based projects.  That will never change.
>
> Another somewhat similar example is ES6 - where a lot of new capabilities
> are added without breaking anything about the underlying ES5.
>
> By now I think the idea should be obvious - what if we did something
> similar for PHP?
>
> Essentially - radically slow down the amount of language-level (read:
> syntax) changes - both additions, deprecations and modifications in PHP
> itself;  But, simultaneously - make the engine understand a new flavor of
> the language (phure?  phun?  phlex?  phuture?) - a flavor where we'd in
> fact be able to introduce a wide range of changes overnight - a lot more
> rapidly than even folks in the former camp feel comfortable doing today.
> Since the vast majority of contention between the two camps has to do with
> either downwards compatibility or 'language fit' - introducing a new flavor
> of the language, which is available in addition to the current one instead
> of replacing it - can provide a fundamental solution to both of these
> points of contention.
>
> We actually have a substantial advantage over both of the above-mentioned
> language sets (C/C++ and JS/ES6) as for all practical purposes - we control
> the single relevant implementation of the language.  At this point - I also
> see no reason of why that implementation wouldn't be able to handle both
> flavors of the language - sharing the same compiler and runtime - and
> allowing them to run simultaneously alongside each other, in a similar way
> that C++ code can run and interoperate with C code at runtime, despite
> being substantially different languages.  The runtime will simply know how
> to run in two different modes - depending on the file at hand - similarly
> to how we do strict types (and we could probably entertain other options as
> well, like doing it on a namespace level).
>
> I want to illustrate what I think this will buy us, at least from my POV.
>
> In P++ (temp code name) - we'd be able to get rid of elements that have

[PHP-DEV] Bringing Peace to the Galaxy

[Zeev Suraski]

[... 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