Bringing Peace to the Galaxy

[... and not in the Sith Lord kind of way.]

Looking at some of the recent (& not so recent) discussions on internals@,
some of the recent proposals, as well as some of the statements made
regarding the future direction of the language - makes it fairly clear that
we have a growing sense of polarization.

As Peter put it yesterday (I may be paraphrasing a bit) - some folks just
want to clear some legacy stuff. I think that in practice it goes well
beyond that - many on internals@ see parts of PHP as in bad need of repair
(scoop: I agree with some of that), while other capabilities, that exist in
other competing languages - are - in their opinion - sorely missing.

At the other end of the spectrum, we have folks who think that we should
retain the strong bias for downwards compatibility we always had, that PHP
isn't in dire need of an overhauling repair and that as far as features go

• less is more - and we don't have to race to replicate features from other
  languages - but rather opt for keeping PHP simple.

To a large degree, these views are diametrically opposed. This made many
internals@ discussions turn into literally zero sum games - where when one
side 'wins', the other side 'loses', and vice versa.

It's fair to say that I'm a lot closer in the way I view things to the
latter camp that the former one. But, at the same time - I understand that
there's merit to the other POV. Even when my POV 'wins', it often feels as
a bit of a Pyrrhic victory, as the negative vibes from these zero sum
discussions and the feeling of disappointment felt by folks in the other
group - many of which I have very high respect for - are definitely not
good for the project (I hope that at least some of them feel in the same
way when things happen in reverse).

Now, what if there was a way to truly make both 'camps' happy? I think
there may be.

There are several successful examples for how languages evolved
dramatically while doing exactly that - retaining downwards compatibility
while introducing radical changes - including compatibility breaking ones -
at the same time.

The most obvious example that comes to mind if C++. It's a whole new
language, that clearly borrows a much of its basic syntax from C, but also
adds many fundamental new features on top of it - and changes behavior in
many situations. When I say that C++ is compatible with C - it's not that
you can run (or compile) any given piece of C code on C++ - you definitely
cannot - but you can call C code from C++ code fairly transparently, and
you wouldn't have to change anything at all in your C code. If you have a
piece of code written in C and you don't care about C++ - you don't have to
do anything at all. In the same way, if you're a C developer, and don't
care much for C++ - you're not forced to learn it - as long as you work on
C-based projects. That will never change.

Another somewhat similar example is ES6 - where a lot of new capabilities
are added without breaking anything about the underlying ES5.

By now I think the idea should be obvious - what if we did something
similar for PHP?

Essentially - radically slow down the amount of language-level (read:
syntax) changes - both additions, deprecations and modifications in PHP
itself; But, simultaneously - make the engine understand a new flavor of
the language (phure? phun? phlex? phuture?) - a flavor where we'd in
fact be able to introduce a wide range of changes overnight - a lot more
rapidly than even folks in the former camp feel comfortable doing today.
Since the vast majority of contention between the two camps has to do with
either downwards compatibility or 'language fit' - introducing a new flavor
of the language, which is available in addition to the current one instead
of replacing it - can provide a fundamental solution to both of these
points of contention.

We actually have a substantial advantage over both of the above-mentioned
language sets (C/C++ and JS/ES6) as for all practical purposes - we control
the single relevant implementation of the language. At this point - I also
see no reason of why that implementation wouldn't be able to handle both
flavors of the language - sharing the same compiler and runtime - and
allowing them to run simultaneously alongside each other, in a similar way
that C++ code can run and interoperate with C code at runtime, despite
being substantially different languages. The runtime will simply know how
to run in two different modes - depending on the file at hand - similarly
to how we do strict types (and we could probably entertain other options as
well, like doing it on a namespace level).

I want to illustrate what I think this will buy us, at least from my POV.

In P++ (temp code name) - we'd be able to get rid of elements that have
little going for them other than backwards compatibility - such as short
tags (not sure about hebrev :)).

But more importantly - we could make much more radical changes a lot more
quickly. Since migration would be opt-in - we won't have to worry about
breaking people's code, and will be able to (and probably should) introduce
all of these things overnight, so that they're a part of a consistent new
paradigm and not a slow steady stream of breakage. We could (and probably
should) make it strict from the get go - and not just with types - but also
with ops, variable declarations, etc. We could change array behavior to
differentiate between integers and integer-looking-numbers. And probably
quite a few other things that currently bother some of us. And we could do
all that without sacrificing compatibility.

There's another advantage to doing that - it will allow us to rebrand.
It's no secret that PHP has a negative reputation among many developers.
Without getting into the question of whether it's justified or not -
starting with something that's a lot closer to a clean slate - and under a
different name - can make a much bigger impact than slow, gradual evolution
under the same name (which, as I've been working hard to illustrate for a
long time, also has substantial downsides).

Now, the PHP (old/current) flavor won’t stagnate either - it will still
benefit from evolution in extensions, other evolving pieces (like JIT or
other improvements in the runtime) and security updates. Things which
those who care primarily about keeping their code working, or that don’t
care for an ever evolving stricter language (and there’s many of them) -
will be able to continue enjoying.

I admit, I haven't thought about every possible corner case we may have
here, and it's still very raw. But at a high level, it seems to make a lot
of sense to me, and I think the advantages of going in this direction -
both technology related, and in restoring calm (and perhaps even renewing
enthusiasm) around internals@ - are strong enough for us to brainstorm
about it.

Thoughts?

Zeev

This is basically what I have been advocating for a while now already,
somewhat hidden between all the other noise of the "namespace-scoped
declares" thread. The model I would like to follow are Rust editions (
https://doc.rust-lang.org/edition-guide/editions/index.html). In PHP right
now, the way to do this technically would be based on a
declare(edition=2020) in every file. I was hoping to make this a
per-package declaration instead, but haven't found the perfect way to do
this right now.

I think that introducing this kind of concept for PHP is very, very
important. We have a long list of issues that we cannot address due to
backwards compatibility constraints and will never be able to address, on
any timescale, without having the ability of opt-in migration.

I do plan to create an RFC on this topic.

Nikita

[... and not in the Sith Lord kind of way.]
Thoughts?

I'm going to speak strictly as a userland PHP developer, for that is
what I am.

The idea of PHP being held hostage to eternal backwards compatibility
fills me with absolute dread.

I've built most of my career on PHP, I find it a very powerful platform,
but I find it lacking in some major areas. Some of those have reasonable
workarounds (React, Swoole) and some of them do not (var level type
enforcement, generics, universal annotations, first class functions and
other symbols, union types, CoW classes etc).

I hope that some day, these problems are going to be fixed, but in the
process I understand they may pose backwards compatibility issues.

If PHP as a language cannot push forwards out of a concern for perpetual
backwards compatibility, then I have to start questioning if it makes
sense for me, and those I work with, to continue using it in the long
run, vs a platform which is willing to find a way to make those changes
and push things forward. I'm thinking 5 - 10 years here.

As a developer, having to spend time on fixing BC breaks is obviously a
cost. However, not having things that would have saved me time, or
allowed me to write better code if they were there, but weren't added
because of BC, is also a cost.

To my mind, I would be happy to see a situation where I can stick a
declare in my file that says "Give me the good stuff and I will find a
way to deal with the BC breaks".

I can deal with short term pain for long term gain.

What I would struggle to deal with is committing myself and my clients
to a language and ecosystem where history was constantly allowed to
trump pragmatism.

I understand it's obviously a big challenge for the internals team and
its contributors to create coexistent systems with versioning, but I
would simply offer the following:

If you're not going forward, you're falling behind, and sometimes going
forward requires sacrifice.

Mark Randall

чт, 8 авг. 2019 г. в 22:17, Zeev Suraski zeev@php.net:

[... and not in the Sith Lord kind of way.]

snip

Thoughts?

Zeev

Apparently, this exists: "ezmlm-reject: fatal: Sorry, I don't accept
messages larger than 30000 bytes (#5.2.3)", so re-sending with Zeev's part
sniped out :)

Good day everyone,

after literally sleeping on it and stewing for the most part of the morning
to gather the thoughts and read other's feedback, here are my 0.02$ as a
userland developer who has been on the list for 10+ years :)

TL;DR.
I think the proposal will not work. C++ worked because it was a completely
different time, target audience and environment that does not exist in our
day and just plain old lack of a team/resources to pull this behemoth of a
feat (but if that would happen successfully, we will have to assign each
of the developers an official status of "Wizzard").

The long version:

Reason 1: Community and ecosystem.

Just look back at how the adoption of 7.1 became to be - if Zeev is saying
"overnight" for P++ and means 2-3 years of work, 7.1 was
adopted/supported/became the minimum required essentially instantly. I mean
it did not take even 6 months for major frameworks, communities and
libraries to announce 7.1 support in next major versions or even 7.1
becoming the next minimum required. Some made plans even before 7.1 landed.
I mean try updating a project to latest versions of libraries/frameworks
today and still stay on 7.0 or 5.6. It is literally impossible because the
community has moved on.
What my feeling is that either majority will just jump ship to the new P++
or it will get ignored. All that means is that one or the other part will
just lack the ecosystem support to survive the transition.
I have to say I'm sorry, but today there are just too many alternatives to
PHP that work just fine and fragmenting PHP into 2 language branches is
just a bad idea. One of the primary reasons PHP did not succumb to winds of
popularity and people returning to it for a more sane and stable
environment is its ecosystem of robust libraries, tools and framework and
people behind them keeping up to date with modern developments.
I mean, just look at the 5 to 7 transition in the last 4 years - people
dropped BC support like crazy, most of the complaints got "adapt or die"
treatment and a lot of people ended up quite happy after doing the
upgrades. Many discovered that the problem was a fly rather than an
elephant. Tooling was available to automate transitions.

Reason 2: Fragmentation, adoption

Look at what happened to Hack - that is basically P++ in a nutshell. It got
dropped by everyone as soon as PHP 7 got the speed boost and Hack team just
saw no more reason to have anything to do with PHP. They also had trouble
implementing or supporting parts of PHP functionality.
In a sense, I could say the experiment got it's test run and failed.

Reason 3: Evolution and resources

Maintaining 2 versions of PHP will be daunting, to say the least. In not so
distant past PHP core had a lack of resources to even maintain the primary
implementation. I really really do not think the PHP core team has the
bandwidth to do a P++. And while C is not by any means dying, it's scope of
use is somewhat limited in a commercial application these days and it is
hard to find jobs, meaning the pool of people who are able to skill up and
contribute is small.
If anything, I think the majority of people will jump the P++ bandwagon and
not pay any attention to the PHP. So a handful of core devs will end up
with the responsibility to maintain the PHP core and poor all their
available time into it or just give up on it. I know I would jump the
bandwagon in that situation without a second thought even if I'm trying to
tell myself I'm a more responsible developer. I'm lying to myself :)

Reason 4: Suggested features and modes.

Going basically statically typed - thanks, but no thanks. There are
numerous languages that are statically typed that are suitable for web
development and that could and should be used in such an environment is
desired. I know people who moved back into PHP because they wanted a more
relaxed environment. I think declare(strict_types=1) mode got it right
and future efforts to enhance that model should be the focus.
I mean we ALREADY have 2 versions of PHP going - weak mode and strict mode.
What if we just double down on the strict mode? I mean, I just had a wild
idea - if a file is included from a "declare(strict_types=1)" scope - do
not allow <? usage.
If anything, we can introduce "declare(strict_mode=1)" for all such stuff
(it will include strict_types) and this makes it opt-in and a valid upgrade
path that actually can be done on a per-file basis.

As a userland developer, I don't really want the core concept of PHP to
change. It evolved nicely over time and I actually am on a steady moderate
evolution side of things. If anything, these days a lot more effort should
be put into fixing some of the extensions khm~PDO~khm and maybe working
on some of the async and of course, don't forget the JIT - that will be a
huge focus in next few years and can yield huge benefits to everyone and
everything.

Reason 5: The issue that spawned this thread

What did tick me off about the short tag removal is the fact that there is
an agreement on engine level behaviour switches need to be all removed.
Short tags, as RFC states, is the last one left. I honestly and truly right
now do not care if <? gets grandfathered in as <?= did. Though I'm
opposed to leaving <?, we can make it a permanent parse error if that
makes "code leaks" people happy and leave it there till, idk, PHP10.
What I care about is short_tags = On/Off switch in php.ini surviving the
purge and resulting in a long term promise that was honoured before this
and now will be broken.
P++ does not solve the original issue regardless.

Reason 6: Extensions and parts of the standard library

At this point, I feel, some attention needs to be redirected at maybe
trying to come up with a cleanup solution for the standard library and
handle the PDO that has been a pain in the ass for everyone to a point
people don't really want to touch it and on the userland side it becoming a
pain to work within certain cases and use workarounds.
I mean really the more I work with databases, the more and more PDO
restrictions, bugs or peculiarities I encounter and less and less I want to
work with it. It is in dire need of either PDOv2 or a different solution.

Closing thoughts:

I feel like both hardcore camps Zeev is describing are too way off base and
want basically impossible. The BC crowd is just being unreasonable and only
the tech that evolves realistically survives. You cannot have the BC cake
and eat it, at some point you have to upgrade and update your application
code. I have migrated personally a 5.2 app straight into late 7.0 release.
I did not find it especially hard and the client found the improved
performance and development speedup worth the spend resources. If anything,
it convinced him to pore resources into a proper rewrite of the system. I
consider PHP to be in a good stot, it just needs a bit more spine in
dropping BC things and because we have BC conscious people in the core, a
lot of the times it is done gracefully and very well. But once a decade or
so something comes up that just cannot technically be handled in a good
way. But people have developed tools that automate the transition, there
are validation tools, code style tools that ALL can detect and warn about
planned upcoming BC break. And plan to actually drop the thing involves "a
5-year plan of gracefull depreciation, errors and final removal". What more
the BC crowd wants to be done then? My view on this is this: "They are
being unreasonable because a plan was made, automation tools were
developed, information is being spread out. People's laziness is not a
valid con argument".

The "upgrade everything, BC be dammed" crowd also needs to chill. If you
are so impatient - there is Go, NodeJS with it's JavaScript/TypeScript,
etc. Right now PHP does has somewhat of a plan and direction it is going,
it is going at a decent pace - not too slow, not too fast. The community is
able to adopt the new features and changes in a timely manner and
gracefully introduce their support or requirement without everyone running
like headless chickens. So maybe solidify the plan, make it into an actual
roadmap? That will allow people to make long term plans and decisions and
make BC less of an issue.

There is also the fact that major parts of PHP that were BC already got
handled and BC breaks since 7.1 have been few and far in between. A few
dangling BC issues that are still present just need a final push and we are
going to end up in a somewhat clean state of things. A lot of future work
is either self-contained new features or can be made opt-in behind a
declare statement.

As I have mentioned, why not expand "declare(strict_types=1)" into a
concept of "declare(strict_mode=1)" and put a lot of upcoming RFC stuff
under it? <? removal can go into that, so can go the strict operator RFC
and other things that make PHP a more strict language.

Thank you for reading.

Arvīds Godjuks

+371 26 851 664
arvids.godjuks@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius

My goal is to have two sister languages, with both PHP and P++
being equal among equals

PHP internals is already lacking programming resources to do
everything we want to be doing.

Maintaining two versions at once would be more work, so this idea is
not feasible without a dramatic increase in the number of people
working on PHP core.

I think that we should do our very best to get this
"P++" right the first time,

That's a fundamentally bad approach to designing a system. If an
approach is worth doing, it's worth doing even if it's done poorly.

https://www.amazon.co.uk/Systems-Bible-Beginners-Guide-Large/dp/0961825170

cheers
Dan
Ack

Hello,

[... and not in the Sith Lord kind of way.]

Looking at some of the recent (& not so recent) discussions on internals@,
some of the recent proposals, as well as some of the statements made
regarding the future direction of the language - makes it fairly clear that
we have a growing sense of polarization.

As Peter put it yesterday (I may be paraphrasing a bit) - some folks just
want to clear some legacy stuff. I think that in practice it goes well
beyond that - many on internals@ see parts of PHP as in bad need of repair
(scoop: I agree with some of that), while other capabilities, that exist in
other competing languages - are - in their opinion - sorely missing.

At the other end of the spectrum, we have folks who think that we should
retain the strong bias for downwards compatibility we always had, that PHP
isn't in dire need of an overhauling repair and that as far as features go

• less is more - and we don't have to race to replicate features from other
  languages - but rather opt for keeping PHP simple.

To a large degree, these views are diametrically opposed. This made many
internals@ discussions turn into literally zero sum games - where when one
side 'wins', the other side 'loses', and vice versa.

It's fair to say that I'm a lot closer in the way I view things to the
latter camp that the former one. But, at the same time - I understand that
there's merit to the other POV. Even when my POV 'wins', it often feels as
a bit of a Pyrrhic victory, as the negative vibes from these zero sum
discussions and the feeling of disappointment felt by folks in the other
group - many of which I have very high respect for - are definitely not
good for the project (I hope that at least some of them feel in the same
way when things happen in reverse).

Now, what if there was a way to truly make both 'camps' happy? I think
there may be.

There are several successful examples for how languages evolved
dramatically while doing exactly that - retaining downwards compatibility
while introducing radical changes - including compatibility breaking ones -
at the same time.

The most obvious example that comes to mind if C++. It's a whole new
language, that clearly borrows a much of its basic syntax from C, but also
adds many fundamental new features on top of it - and changes behavior in
many situations. When I say that C++ is compatible with C - it's not that
you can run (or compile) any given piece of C code on C++ - you definitely
cannot - but you can call C code from C++ code fairly transparently, and
you wouldn't have to change anything at all in your C code. If you have a
piece of code written in C and you don't care about C++ - you don't have to
do anything at all. In the same way, if you're a C developer, and don't
care much for C++ - you're not forced to learn it - as long as you work on
C-based projects. That will never change.

Another somewhat similar example is ES6 - where a lot of new capabilities
are added without breaking anything about the underlying ES5.

By now I think the idea should be obvious - what if we did something
similar for PHP?

Essentially - radically slow down the amount of language-level (read:
syntax) changes - both additions, deprecations and modifications in PHP
itself; But, simultaneously - make the engine understand a new flavor of
the language (phure? phun? phlex? phuture?) - a flavor where we'd in
fact be able to introduce a wide range of changes overnight - a lot more
rapidly than even folks in the former camp feel comfortable doing today.
Since the vast majority of contention between the two camps has to do with
either downwards compatibility or 'language fit' - introducing a new flavor
of the language, which is available in addition to the current one instead
of replacing it - can provide a fundamental solution to both of these
points of contention.

We actually have a substantial advantage over both of the above-mentioned
language sets (C/C++ and JS/ES6) as for all practical purposes - we control
the single relevant implementation of the language. At this point - I also
see no reason of why that implementation wouldn't be able to handle both
flavors of the language - sharing the same compiler and runtime - and
allowing them to run simultaneously alongside each other, in a similar way
that C++ code can run and interoperate with C code at runtime, despite
being substantially different languages. The runtime will simply know how
to run in two different modes - depending on the file at hand - similarly
to how we do strict types (and we could probably entertain other options as
well, like doing it on a namespace level).

I want to illustrate what I think this will buy us, at least from my POV.

In P++ (temp code name) - we'd be able to get rid of elements that have
little going for them other than backwards compatibility - such as short
tags (not sure about hebrev :)).

But more importantly - we could make much more radical changes a lot more
quickly. Since migration would be opt-in - we won't have to worry about
breaking people's code, and will be able to (and probably should) introduce
all of these things overnight, so that they're a part of a consistent new
paradigm and not a slow steady stream of breakage. We could (and probably
should) make it strict from the get go - and not just with types - but also
with ops, variable declarations, etc. We could change array behavior to
differentiate between integers and integer-looking-numbers. And probably
quite a few other things that currently bother some of us. And we could do
all that without sacrificing compatibility.

There's another advantage to doing that - it will allow us to rebrand.
It's no secret that PHP has a negative reputation among many developers.
Without getting into the question of whether it's justified or not -
starting with something that's a lot closer to a clean slate - and under a
different name - can make a much bigger impact than slow, gradual evolution
under the same name (which, as I've been working hard to illustrate for a
long time, also has substantial downsides).

Now, the PHP (old/current) flavor won’t stagnate either - it will still
benefit from evolution in extensions, other evolving pieces (like JIT or
other improvements in the runtime) and security updates. Things which
those who care primarily about keeping their code working, or that don’t
care for an ever evolving stricter language (and there’s many of them) -
will be able to continue enjoying.

I admit, I haven't thought about every possible corner case we may have
here, and it's still very raw. But at a high level, it seems to make a lot
of sense to me, and I think the advantages of going in this direction -
both technology related, and in restoring calm (and perhaps even renewing
enthusiasm) around internals@ - are strong enough for us to brainstorm
about it.

Thoughts?

Zeev

From my understanding the core thought and philosophy here is very
great. Also thank you that we even have such discussion. It shows that
PHP cares for future changes after all. Maybe instead of making two
languages there probably is also some kind of other middle way (like
it was mentioned in one of your emails in the past I think a bit):
Something such as "legacy" extension (or better named to not cause
issues with meaning that something like short tags will go away in
future - the "traditional" extension) or something like that.
Where developer would have option to enable it and use "traditional"
or whatever named PHP functionalities such as short tags and things
that cause so many issues and being sidelines. Without enabling (or
importing that), PHP would behave more futuristic oriented.

There will still be a need to take compromises in either case. Even in
the PHP vs PHP++ case where people will want to change something in
the PHP or do differently in PHP++. That's quite normal. Important
thing is that everyone has a bit of an overview of everyone else also.
One camp that recommends going without short tags and the other that
wants these in, as an example.

--
Peter Kokot

3. Putting your apparent personal bias against backwards compatibility
   aside - if P++ goes in the directions you're hoping for - towards giving
   you the goodies on your wish list, why would you care if PHP still existed
   without these new changes/features?

Zeev

Another userland developer here. I'd just like to share my abject terror of
the idea that the language might split into two.

Having made a toy transpiler (https://github.com/hacktophp/hacktophp) from
Hack code to PHP, I don't think that's a good way forward either.

The Python 2 => 3 migration is a good example of a language maintaining its
popularity despite an uncomfortable upgrade, and I think that bump has
helped secure Python's relevance for the next decade.

Though PHP is uncool, it's still popular. Have faith that the community
won't abandon PHP if the language improves.

...

3. Putting your apparent personal bias against backwards compatibility
   aside - if P++ goes in the directions you're hoping for - towards giving
   you the goodies on your wish list, why would you care if PHP still existed
   without these new changes/features?

Zeev

I just want to express a personal bias - joy at reading the proposal. Our php
code goes back to approx 2002. We did get a performance improvement
moving to PHP7 and it has allowed us to integrate with third party modules
that were not compatible with PHP5, but it also required many, many hours
that were not spent moving our application forward in other ways. I think the
#1 reason for changing PHP versions for us is security policy. If a PHP version
is "end of life" we must move on, no matter how much pain it causes and how
perfectly acceptably everything was functionally running on the older version.
The idea of having code that works be allowed to continue to work is very,
very appealing.

I don't want people who want to go in bold new directions to be held back;
the proposal seems like something that would help me sleep more peacefully
while allowing the adventurous to proceed. Thanks!

• Todd (usually quiet here)

2. Different people have different preferences. There's a reason that not
   everyone is using the same language, or have the same mobile phone or the
   same car. Something it's not 'forward' or 'backwards' - it's about
   'different'. Is C++ better than C? Many would argue that it is, while
   others will argue that it's not. Both can be correct, it's ultimately not
   only a matter of objective truths, but also subjective perceptions,
   preferences and the tasks at hand.

I'd say C++ gives you extra tools to do the job you want to do, and to
do them quicker, and safer (std::string vs char[]).

3. Putting your apparent personal bias against backwards compatibility
   aside - if P++ goes in the directions you're hoping for - towards giving
   you the goodies on your wish list, why would you care if PHP still existed
   without these new changes/features?

I'm not inherently biased against BC. But it doesn't exist in isolation,
in my mind I have to weigh the benefits of BC with the benefits that
breaking BC could bring. IMO, long term, the former is greatly
outweighed by the latter.

The thing is, I don't see PHP diverging in the way you suggest. I
suspect it would end up being versioned within the same application,
even though I suspect that would be much harder to pull off, it may end
up that it's not actually possible.

I was trying to think of something which could easily break if passed
between two versions, and something which immediately came to mind was
union types and reflection, a method which returned one string would
need to return an array, or just the first, and so on.

A "separate" version would certainly be easier. The ability to rip out
everything which wasn't kept would no doubt simplify a lot of things,
but I agree with Nikita's point that it only kicks things down the line
until the next break.

I think side-by-side engine versions are likely going to be the end
result if it's possible.

My heart says "clean break" my head says "side by side".

Mark Randall

Joe,

Top posting on purpose because you seem to focus on the 'overnight' element
while not understanding quite what I meant (I'll take the blame for that) -
and therefore deriving irrelevant conclusions.

When I'm saying "overnight", I mean from the end users' perspective. In
the same way that C++ didn't gradually roll out its features as a slow
steady stream - but rather, was made available one day with a lot of new
capabilities - essentially a new language - that would be the same idea
here.

It doesn't mean it'll happen on August 10th, at least not 2019. It may
take 2 or 3 years to complete. But once we have it ready - it'll be made
available in one installment, with all the major issues that are on the top
list of folks handled. That is, in contrast to breaking some stuff, and
then breaking some more a few years down the line.

Zeev

Morning all,

First, I want to say that I don't think the polarisation claimed to be
occurring is actually occurring. The vast majority of internals voters
appear to judge each RFC on it's own merit, while some of them give more
weight to retaining bc than others and that effects their vote, they didn't
decide how they are going to vote before reading the proposal. There are
some very vocal internals mailing list contributors that may give the
impression that there is much more dissent, from many more people, or much
more controversy than there actually is. A thread is not controversial if
some high percentage of the correspondence is from one or two person, it's
spammy.

When it comes to the proposal being made, that we develop ++ "overnight"
and "get everything right the first time" ... I'm not sure how serious
these statements are, on their face, they don't make much sense, although
they may just be the result of extreme optimism rather than non-thinking.

When it comes to the idea of editions, this would appear to have actual
merit, there's some overlap with the ++ idea, but they are distinct, and
editions and a more forward looking sustainable solution to the problems we
are facing and will continue to face.

Now I just want to point out the subtle difference between editions, and
versions of a language (whatever it's name) ...

Should we take up proposal one, and [magically] develop an overnight
language, we would have to version subsequent releases as per our
versioning guidelines, they would be subject to the same bc concerns that
versions of PHP are today. We would find eventually ourselves in exactly
the same position with ++ as we are with PHP.

Should we take up proposal two, and start to develop opt-in editions to be
released alongside minor releases, these editions do not need to have the
same BC concerns as regular PHP. Should we make a horrible mistake in some
edition, we don't need to take 10 years to fix it, we may even fix it in
the very next edition.

Cheers
Joe

2. Different people have different preferences. There's a reason that
   not
   everyone is using the same language, or have the same mobile phone or
   the
   same car. Something it's not 'forward' or 'backwards' - it's about
   'different'. Is C++ better than C? Many would argue that it is, while
   others will argue that it's not. Both can be correct, it's ultimately
   not
   only a matter of objective truths, but also subjective perceptions,
   preferences and the tasks at hand.

I'd say C++ gives you extra tools to do the job you want to do, and to
do them quicker, and safer (std::string vs char[]).

3. Putting your apparent personal bias against backwards compatibility
   aside - if P++ goes in the directions you're hoping for - towards
   giving
   you the goodies on your wish list, why would you care if PHP still
   existed
   without these new changes/features?

I'm not inherently biased against BC. But it doesn't exist in isolation,
in my mind I have to weigh the benefits of BC with the benefits that
breaking BC could bring. IMO, long term, the former is greatly
outweighed by the latter.

The thing is, I don't see PHP diverging in the way you suggest. I
suspect it would end up being versioned within the same application,
even though I suspect that would be much harder to pull off, it may end
up that it's not actually possible.

I was trying to think of something which could easily break if passed
between two versions, and something which immediately came to mind was
union types and reflection, a method which returned one string would
need to return an array, or just the first, and so on.

A "separate" version would certainly be easier. The ability to rip out
everything which wasn't kept would no doubt simplify a lot of things,
but I agree with Nikita's point that it only kicks things down the line
until the next break.

I think side-by-side engine versions are likely going to be the end
result if it's possible.

My heart says "clean break" my head says "side by side".

Mark Randall

Morning all,

First, I want to say that I don't think the polarisation claimed to be
occurring is actually occurring. The vast majority of internals voters
appear to judge each RFC on it's own merit, while some of them give more
weight to retaining bc than others and that effects their vote, they didn't
decide how they are going to vote before reading the proposal. There are
some very vocal internals mailing list contributors that may give the
impression that there is much more dissent, from many more people, or much
more controversy than there actually is. A thread is not controversial if
some high percentage of the correspondence is from one or two person, it's
spammy.

I agree. For the most part, the issue isn't with BC breaks in general.
Short tags has become very contentious because those against removing them
(like myself) see a HUGE downside to removing them and little, if any,
upside. That's where the contention is coming from. I think some of the
people on the pro-removal side have framed it as if those against removal
were against BC breaks in general. Others then come along and scan through
the thread and think the issue is a "BC good" vs "BC bad" one.

I'm one of the people that has been pretty vocal against removing short
tags. At this point, I'm not a huge fan of this proposal. I can't point to
anything specific - it just doesn't feel right. I think one of the reasons,
though, is because I'm not against BC breaks in general.

When it comes to the proposal being made, that we develop ++ "overnight"

and "get everything right the first time" ... I'm not sure how serious
these statements are, on their face, they don't make much sense, although
they may just be the result of extreme optimism rather than non-thinking.

As developers I think we all know that you'll never get anything right the
first time. No matter how much thought and effort is put in ++, there are
things that are going to be outdated, abused, or simply unnecessary further
down the road. Then we'll be back where we started when it comes to BC
breaks.

When it comes to the idea of editions, this would appear to have actual
merit, there's some overlap with the ++ idea, but they are distinct, and
editions and a more forward looking sustainable solution to the problems we
are facing and will continue to face.

Now I just want to point out the subtle difference between editions, and
versions of a language (whatever it's name) ...

Should we take up proposal one, and [magically] develop an overnight
language, we would have to version subsequent releases as per our
versioning guidelines, they would be subject to the same bc concerns that
versions of PHP are today. We would find eventually ourselves in exactly
the same position with ++ as we are with PHP.

Should we take up proposal two, and start to develop opt-in editions to be
released alongside minor releases, these editions do not need to have the
same BC concerns as regular PHP. Should we make a horrible mistake in some
edition, we don't need to take 10 years to fix it, we may even fix it in
the very next edition.

Cheers
Joe

2. Different people have different preferences. There's a reason that
   not
   everyone is using the same language, or have the same mobile phone or
   the
   same car. Something it's not 'forward' or 'backwards' - it's about
   'different'. Is C++ better than C? Many would argue that it is, while
   others will argue that it's not. Both can be correct, it's ultimately
   not
   only a matter of objective truths, but also subjective perceptions,
   preferences and the tasks at hand.

I'd say C++ gives you extra tools to do the job you want to do, and to
do them quicker, and safer (std::string vs char[]).

3. Putting your apparent personal bias against backwards compatibility
   aside - if P++ goes in the directions you're hoping for - towards
   giving
   you the goodies on your wish list, why would you care if PHP still
   existed
   without these new changes/features?

I'm not inherently biased against BC. But it doesn't exist in isolation,
in my mind I have to weigh the benefits of BC with the benefits that
breaking BC could bring. IMO, long term, the former is greatly
outweighed by the latter.

The thing is, I don't see PHP diverging in the way you suggest. I
suspect it would end up being versioned within the same application,
even though I suspect that would be much harder to pull off, it may end
up that it's not actually possible.

I was trying to think of something which could easily break if passed
between two versions, and something which immediately came to mind was
union types and reflection, a method which returned one string would
need to return an array, or just the first, and so on.

A "separate" version would certainly be easier. The ability to rip out
everything which wasn't kept would no doubt simplify a lot of things,
but I agree with Nikita's point that it only kicks things down the line
until the next break.

I think side-by-side engine versions are likely going to be the end
result if it's possible.

My heart says "clean break" my head says "side by side".

Mark Randall

--

--
Chase Peeler
chasepeeler@gmail.com

I'm unable to follow that part either. Would appreciate some further
elaboration to make it clearer what you have in mind in these three
paragraphs...

My read of what Nikita was suggesting was some kind of per-file or
per-package versioning system that would operate at compile time to add
new features at compiler / parser level, and presumably keep them
running on the same VM.

What I am less sure about is how it would handle BC between versions of
the API, the example I gave was reflection and union types.

Perhaps I mistook his intention.

Mark Randall

You seem to believe that C++ is inherently superior to C. And it's
entirely within your right.
However, there are projects - to this date - that prefer C to C++ for a
variety of reasons. PHP is one of them, and others include the Linux
kernel, redis, nginx, and actually - the vast majority of the fundamental
pieces of OS infrastructure our planet runs on. This isn't just for
historical reasons - it has to do with a variety of reasons, and the
simplicity of C is one of them.

I just wanted to amend a bit of present day context, as it happens,
security management at Microsoft is currently giving serious
consideration to moving away from C / C++ and on to memory safe
languages because of the benefits they bring.

https://www.theregister.co.uk/2019/07/18/microsoft_rust_security/

we’re discussing whether it makes sense to introduce a sister language to PHP.

Zeev also wrote:

It will take no additional resources,

First, those two statements are mutually exclusive.

Second, the idea of keeping PHP as it currently is, and pushing people
who want to evolve the language out from core PHP to make their own
language, is effectively telling those people to make a fork of the
project.

This is not an appropriate thing to suggest.

Please stop trying to regain control of the PHP project either through
direct threats or through telling people that they should fork off the
project if they want to evolve PHP.

I strongly feel the conversations you are provoking on internals are
not productive or healthy for the project.

cheers
Dan
Ack

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.

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.