P++: FAQ

2. Strict(er) typing - I'm not sure, on the surface, what future expansions
   we'd plan for in this area which couldn't fit into standard PHP in a non
   BC-breaking way.

Union types and general reflection do spring to mind on this. I assume
any APIs using them would need to return more complex objects describing
them, rather than individual strings from getType().

Typed arrays are also another one which has been in high demand that I
imagine will present some BC issues if shared between stricter and
less-strict code.

From what else I have read on here, the real biggy is probably going to
be generics (hallowed by thy name).

3. Failing closed. Things like strpos() being able to return int(0) which
   is a falsey value. This has been a long standing "complaint" about PHP
   which isn't actually "fixable" without a big BC fail. We've already shown
   we're willing to bite this bullet for security issues
   (openssl_random_bytes).

strpos returning 0 for the start makes perfect sense to me, what doesn't
make sense is returning false. I think these problems need to be
murdered-to-death with scalar objects (ideally returning -1 or, at a
push, null, because at least the return type could be expressed as ?int,
but IMO -1 is far superior).

I think scalar would be a huge game changer for allowing more sensible
function names / return types without completely killing backwards
compatibility on the existing core functions.

The entire argument order issue could potentially be wrote off with SON.

My guess is that whatever happens, it's going to require one version
that really brings the pain, to set the groundwork for the future.

Mark Randall

It's available here: https://wiki.php.net/pplusplus/faq

It's possible I missed something while on holiday. There are certainly a
lot of messages to page through. I dig the idea of resolving this
tug-of-war between progress and BC, but I'm not 100% clear on what the
final goals are. I understand that we're talking about more aggressively
breaking BC in this new mode while preserving BC in "normal" PHP files, but
I think it would help the conversation if we enumerated specific aims.

Some guesses on what we're talking about:
[snip]
Am I completely off base?

I don't think you are. In addition to these and those brought up by Mark -
other things could be making the new dialect stricter across the board -
including operators, array indices; Requiring variable declarations;
Potentially changing some conversion rules (for explicit conversions), and
potentially changing some operator behavior (not just in terms of
strictness).

As Bob pointed out I'm rusty, but I do think that we can solve the short
tags issue in this way. At the lexer level, if we see the <?p++?> tag, we
set short tags to off for the scope of the file before moving forward. But
more importantly, this approach can allow us to implement different BC
breaking strategies (and not just for language features, but also for
built-in functions).

Zeev

On Fri, Aug 9, 2019 at 7:08 PM Larry Garfield larry@garfieldtech.com
wrote:

During the discussion of the P++ proposal (
https://externals.io/message/106453), it became painfully clear that
this
idea did little, so far, to bring peace to the galaxy.

However, based on a lot of the feedback, both on internals@ and
elsewhere -
it seems that a lot of people simply didn't really understand what this
idea was actually proposing to do. I'll take the blame for that - by not
making the idea sufficiently clear.

I went on and create an FAQ, that attempts to address many of the
questions
and common misconceptions that repeatedly came up.

It's available here: https://wiki.php.net/pplusplus/faq

Before you read it, I want to stress that this is an attempt to
provide *everyone
with a good deal, and nobody with a raw deal. *It doesn't mean it's
successful at that (although I think it is) - but the motivation is clean
and positive. If & when you read this FAQ, please try to read it without
any preconceived notions.

If there are additional questions that you think are missing, please let
me
know - or better yet, if you're up for constructively adding them - go
ahead and do that.

Thanks,

Zeev

Zeev,

First off, I want to be clear that I appreciate your efforts at
conciliation here, and firmly believe your intent is benevolent.

However, I ask you to consider that, intent or not, it's really easy for
this proposal and some of your comments to come off as "strict people, go
away and have your own corner". That is likely not helping the discussion.

Arvids Godjuks has already covered in great deal most of my issues with
this proposal. There's a few key additional points I want to bring up,
though.

First, as Sara observed I feel like this is conflating a number of
different threads into a single binary question.

There are "cleanup" type issues, such as short open tags, strpos() return
values, strict comparisons, and so forth. The main concern here is BC. I
suspect that, were we only concerned with greenfield projects and nothing
else, these would be entirely uncontroversial and most people would be fine
with them. The main difference of opinion here isn't "how should the
language evolve" but "how do we balance BC concerns with fixing design
flaws, mostly from PHP's early days"?

I don't think anyone can reasonably argue that strpos() returning false
for not-found, which == 0, is a good design; but "it's not bad enough
design to justify breaking a billion lines of code" is a strong argument,
and one on which reasonable people can reasonably disagree. (And on which
we can, and should, explore creative alternative approaches to "just break
it".)

Then there's an entirely different class of question regarding future
additions. Should PHP support union types, for instance. That change has
no BC implications whatsoever. If PHP added union types, existing code
would continue to run perfectly fine with no issue whatsoever. New code
that used union types wouldn't run on old PHP versions, naturally, but
that's expected and is still not a BC issue. The argument here is entirely
different: "Great, one more thing I have to learn because someone is going
to use it and I have to read it" vs. "This saves me so much time writing
and debugging code, yay". Again, reasonable people can reasonably disagree
here.

These are two almost entirely separate and orthogonal questions. There's
a few places where they touch -- mostly around bugs that are bugs only
because of type juggling logic being non-intuitive at times -- but from a
philosophical point of view they have nothing to do with each other. Your
proposal conflates them unnecessarily, and I think that's a crucial flaw in
it.

For example, suppose PHP++ mode gets union types, and has strpos() changed
to return something safer, and has short-tags removed, while PHP-oldschool
does not. If I want to use union types... I still have to make just as
many changes to my code, including potentially cleaning up 10000 instances
of strpos() in my huge legacy codebase just so that I can use a union type
in new code. I have gained... extremely little here. Coupling those two
changes has not created any benefit, just more confusion and annoyance.

Exactly. I think this is what I worry about the most with this. I'm
against removing short tags. I don't use type hints myself, but, I have no
problem with the fact they exist. If strict typing were introduced for
declared variables, I would almost definitely never use them - but I don't
mind them getting added. There is SO much that can be added and done to
evolve and improve PHP that doesn't introduce BC breaks. There are also
many things that will cause BC breaks that people will understand and
accept given the positive benefit. I keep feeling like this is all coming
as a result of the people treating the opposition to short tag removal as
being against BC breaks in general.

What about common packages, or interfaces from FIG? If FIG puts out an
interface spec that makes use of a union type (for reasons that are
completely reasonable in context), it's essentially forcing people to use
PHP++ in order to use that spec; PHP-oldschool people are SOL. Conversely,
in order to maintain compatibility with PHP-oldschool FIG would have to
eschew any features not in both branches; essentially not being able to use
language features that are especially valuable for exactly that type of use
case!

Second point, suppose such a dual-mode happens. Fast forward 2 years, and
I find someone to bribe to help me revive the comprehensions proposal
(which has no type considerations, necessarily). Does that go into PHP++
or PHP-oldschool or both?

Essentially, every syntax-affected RFC would have an extra fight over
which PHP flavors get it. That doesn't seem like a polite thing to do to
future generations of core contributors, including future-us.

The only way to short circuit that would be to declare that PHP-oldschool
never gets syntax changes at all, only PHP++ does. Which would be a very
strong signal that, yeah, PHP-oldschool is a dead language and anyone who
isn't WordPress should just switch to PHP++ and be done with it. But since
your FAQ specifically mentions async as something that would be included in
both modes I assume you're not proposing that PHP-oldschool be frozen in
time syntactically, which means this debate would resurface for every RFC.
That's a net loss for all involved.

Finally, Zeev, you mention the "PHP philosophy" of being a dynamic
language. While that may well be your philosophy, and you have every right
to have it, that has not been the "PHP philosophy" for years, as seen by
all of the type "stuff" that's been successfully added to the language and
gone into widespread use. PHP doesn't have a coherent philosophy. It is
proudly directionless, steered by whoever happens to be writing code this
week. A few years back, Anthony Ferrara proposed developing an actual PHP
mission statement to help resolve such debates over direction and was
resoundingly rejected. Rightly or wrongly, to speak of "PHP philosophy" as
a thing one can actually reference is simply not possible.

To end on a positive note, while I agree that there is often a tension on
such questions I think PHP has been remarkable in how well it's navigated
it. I don't know any other language that has managed to evolve as much as
PHP has from 5.3 onward with so little relative BC breakage. The
new-features/breakage ratio for modern-era PHP is, I think, bloody amazing.

And when there has been good-reason breakage, we've rolled with it. PHP
7.0's change to variable evaluation order was, on paper, a massive parser
change... and yet the community rolled with it and upgraded and no one
died. It was a BC break, but a good one, and managed well, and it all
worked out.

On the typing front, the course PHP has been going down in practice is to
have an increasingly robust type system, all of which is opt-in. Frankly I
think that's super cool, and a great way of balancing the prototyping
benefits of dynamic languages (which are most seen at small scale
codebases) and the robustness/safety of more refined type system (which are
most seen in larger code bases) within a single ecosystem. If a given
codebase tends toward one or the other, it does so for a reason. Most tend
toward typed these days, for a reason, but also have places where they
don't where it doesn't make sense to.

That's a balancing act, yes. It's not always an easy balancing act. But
frankly, I'd rather celebrate how well we've been able to pull it off over
the years than lament how hard it is or introduce even more complexity and
inconsistency in an attempt to not have to bother.

--Larry Garfield

--

--
Chase Peeler
chasepeeler@gmail.com

[List etiquette question: is it good form here to change the subject line
when starting a tangential discussion?]

PHP doesn't have a coherent philosophy. It is proudly directionless,
steered by whoever happens to be writing code this week. A few years back,
Anthony Ferrara proposed developing an actual PHP mission statement to help
resolve such debates over direction and was resoundingly rejected. Rightly
or wrongly, to speak of "PHP philosophy" as a thing one can actually
reference is simply not possible.

I have been working on a proposal for a PHP manifesto / mission statement.
I did not know it had been proposed before. [I haven't tracked down
Anthony's proposal - if anyone has a link, I'd appreciate it]

I started for the same reason: to help the community pull together and
argue less, by having a codified set of values.

On this list there are many different factions, all with their own vision
for PHP. If everyone is fighting to "win", it's an unpleasant, tiring
environment, turns people off contributing, and those who "win" can be
those who keep going the longest, not those with the best idea.

I saw a manifesto helping like this:

"Consider a proposal to remove a function from PHP. If PHP had a manifesto,
heated discussions could be minimised:

• Does the manifesto say that maintaining backwards compatibility is more
  important than cleaning up the standard library? Removing it is not inline
  with PHP’s vision.
• Does the manifesto say that rarely-used functions should be removed to
  make the codebase lean? Removing it is inline with PHP’s vision."

Observing the project, I am not hopeful that anything like this could gain
traction without an overhaul of PHP's governance. Someone or some group
would have to have the deciding vote on what went in the manifesto.

In the last few months I have seen:

• Core contributors should have more/the final say on RFC votes
• The PHP user-community should have more say on RFC votes
• The PHP Group have authority over the project
• The PHP Group do not have authority over the project
• A longstanding contributor feels they have a leadership position
• Others feel the longstanding contributor doesn't

I am stating these neutrally, not judging them. Neither am I aiming to
misrepresent positions. If you feel I have, I'm sorry.

I am highlighting that there is no consensus here. I get this is the way
the project has always run (I think of it as the "Linus Torvalds and the
Linux Kernel" meritocracy approach). But: people don't seem happy.

Is there appetite for change?

To end on a positive note, while I agree that there is often a tension on
such questions I think PHP has been remarkable in how well it's navigated
it. I don't know any other language that has managed to evolve as much as
PHP has from 5.3 onward with so little relative BC breakage. The
new-features/breakage ratio for modern-era PHP is, I think, bloody amazing.

I agree, and want to say a big "Thank you" to everyone who made that
happen. The PHP-userland community is too silent about the good things in
PHP, and you who bring the language about deserve way more praise than you
get.

Finally, I am going to wait at least 6 hours, ideally 12 before replying to
responses, and I encourage you to join me in this. My knee-jerk replies can
be more argumentative than I mean them to be, and by slowing down the
conversation I hope we can have a reflective and thoughtful discussion.

Peter

Hi!

Finally, Zeev, you mention the "PHP philosophy" of being a dynamic
language. While that may well be your philosophy, and you have every
right to have it, that has not been the "PHP philosophy" for years,
as seen by all of the type "stuff" that's been successfully added to
the language and gone into widespread use. PHP doesn't have a
coherent philosophy. It is proudly directionless, steered by whoever
happens to be writing code this week. A few years back, Anthony

I don't think that's the case, moreover, I don't think project can exist
and bring coherent results useful to the outside world this way. Of
course, we do not have "mission statement", but those formal
committee-designed ones are a useless baloney in about 99.999% of cases
I've seen. There are, however, certain ideas that underly what is and
what isn't PHP and why people use PHP and not some other language, and
why certain features are done in certain way. Dynamic language has been
one of them, but not only. Pragmatism - preference for solutions that
deliver maximum value for the users to solutions that adhere to one or
another kind of abstract conceptual framework - is another. Low barrier
of entry and embracing users not requiring strong theoretical background
and extensive training to be productive is another. Paving the walkways
and serving the common use case is another. Borrowing concepts proven to
be successful is another. There could be a lot of things, and the list
would probably differ from person to person, but I am pretty sure
"directionless" is not how you properly describe it.

Rightly or wrongly, to speak of "PHP philosophy" as a thing one can
actually reference is simply not possible.

I think not only is it possible, it is necessary. I don't think a
project can exist as a hodgepodge of code that people randomly graft on
whatever they happened to like in the moment. Maybe we have no official
Constitution document, but I think we still have some guiding principles
that PHP have been following over the years of its history.
It doesn't mean everything we have done we have to repeat forever again.
Environment changes, people change, community needs change, and
something we rejected 10 years ago we may embrace now. That's ok, but
this is not the same as being directionless.

Stas Malyshev
smalyshev@gmail.com

+1

I must admit that the first time I read Zeev’s email I got anxious... but
it is frustrating that PHP has a WAY better runtime than Python and most
other dynamic languages yet is falling out of fashion. It’s strange given
how much better it actually runs (really being unbiased here). One reason
is security perception (which is BS but perception matters) and the second
is arguably some of the historic baggage which makes some folks feel PHP is
hard to master without a manual (we have the best manual).

So many times I have thought “is it time to just take an axe and simplify
it and do a cleanup?”. I actually don’t think we lack many features but
rather lots of stuff I would dump like references, array(), global
namespace for functions(?), type juggling in areas where we should be
stricter, etc... I actually think that having a p++ is risky but it is an
opportunity. I think it’s mostly be an opportunity if we’d be careful about
feature bloat and try and be really aggressive about removing things and
cleaning up. We potentially would get the significant benefits of our
runtime but with a cleaner language. Will non-PHP appreciate it? maybe,
maybe not... I actually do think there’s value of a different brand just
because of the BS perception issues...

Andi

Get Outlook for iOShttps://aka.ms/o0ukef

---

From: Zeev Suraski zeev@php.net
Sent: Friday, August 9, 2019 12:54 PM
To: Internals
Subject: [PHP-DEV] P++: FAQ

During the discussion of the P++ proposal (
https://externals.io/message/106453), it became painfully clear that this
idea did little, so far, to bring peace to the galaxy.

However, based on a lot of the feedback, both on internals@ and elsewhere

it seems that a lot of people simply didn't really understand what this
idea was actually proposing to do. I'll take the blame for that - by not
making the idea sufficiently clear.

I went on and create an FAQ, that attempts to address many of the questions
and common misconceptions that repeatedly came up.

It's available here: https://wiki.php.net/pplusplus/faq

Before you read it, I want to stress that this is an attempt to
provide *everyone
with a good deal, and nobody with a raw deal. *It doesn't mean it's
successful at that (although I think it is) - but the motivation is clean
and positive. If & when you read this FAQ, please try to read it without
any preconceived notions.

If there are additional questions that you think are missing, please let me
know - or better yet, if you're up for constructively adding them - go
ahead and do that.

Thanks,

Zeev

I must admit that the first time I read Zeev’s email I got anxious... but
it is frustrating that PHP has a WAY better runtime than Python and most
other dynamic languages yet is falling out of fashion.

In the case of Python, it seems to be the numerical, scientific and linear
algebra libraries that's driving its popularity.

I agree PHP has a way better runtime and it is frustrating to see this
happen.

It’s strange given how much better it actually runs (really being unbiased
here).

If PHP doesn't have the libraries people want, and if PHP is perceived as a
web scripting language rather than a general-purpose dynamic language, then
the better runtime isn't going to convince a large audience that it's the
best tool for the job.

Peter

I must admit that the first time I read Zeev’s email I got anxious... but
it is frustrating that PHP has a WAY better runtime than Python and most
other dynamic languages yet is falling out of fashion. It’s strange given
how much better it actually runs (really being unbiased here). One reason
is security perception (which is BS but perception matters) and the second
is arguably some of the historic baggage which makes some folks feel PHP is
hard to master without a manual (we have the best manual).

So many times I have thought “is it time to just take an axe and simplify
it and do a cleanup?”. I actually don’t think we lack many features but
rather lots of stuff I would dump like references, array(), global
namespace for functions(?), type juggling in areas where we should be
stricter, etc... I actually think that having a p++ is risky but it is an
opportunity. I think it’s mostly be an opportunity if we’d be careful about
feature bloat and try and be really aggressive about removing things and
cleaning up. We potentially would get the significant benefits of our
runtime but with a cleaner language. Will non-PHP appreciate it? maybe,
maybe not... I actually do think there’s value of a different brand just
because of the BS perception issues...

Its extremely hard imho to be in fashion all the time and it takes
anticipation to get next years fashion right. Or you can just wait to get
in fashion again with the good things you already have and incrementally
improve them.

Nothing a PHP / P++ fork will do changes the fact that PHP is a C-style
language, and Python gets praise for its easy to read and understand
syntax. Nothing will change the fact that PHP architecture is primarily
shared nothing, and the current hype is "shared everything" with Node.js
(yes i know about Swoole et al). But why bother? A language can't be
everything.

A different brand might help get a different perception, BUT it also has no
reputation at all at the beginning. If you say "better PHP" (or the likes),
it gets PHPs "reputation" by affiliation automatically and you are at the
same point as before.

What would be the plan to boost or change the reputation? How are you going
to find P++ in Google? How are users searching for things with PHP and P++?
What's the documentation going to look like for two languages that share so
much? Specifically from a marketing POV splitting up the language into two
makes no sense at all. Given PHP has no unified marketing message or a
dedicated department it is much better to use the existing brand, with all
its positive and negative perception and just keep rolling with it.

A strategy to change the security or any other perception of PHP is solely
a marketing, teaching and persistence issue. As you say the language is
already the fastest dynamic language with the best runtime. But "starting
over" with 0 brand name and perception is much harder problem than changing
the existing brand, and its not at all technical challenge.

greetings
Benjamin

Andi

Get Outlook for iOShttps://aka.ms/o0ukef

---

From: Zeev Suraski zeev@php.net
Sent: Friday, August 9, 2019 12:54 PM
To: Internals
Subject: [PHP-DEV] P++: FAQ

During the discussion of the P++ proposal (
https://externals.io/message/106453), it became painfully clear that this
idea did little, so far, to bring peace to the galaxy.

However, based on a lot of the feedback, both on internals@ and elsewhere

it seems that a lot of people simply didn't really understand what this
idea was actually proposing to do. I'll take the blame for that - by not
making the idea sufficiently clear.

I went on and create an FAQ, that attempts to address many of the questions
and common misconceptions that repeatedly came up.

It's available here: https://wiki.php.net/pplusplus/faq

Before you read it, I want to stress that this is an attempt to
provide *everyone
with a good deal, and nobody with a raw deal. *It doesn't mean it's
successful at that (although I think it is) - but the motivation is clean
and positive. If & when you read this FAQ, please try to read it without
any preconceived notions.

If there are additional questions that you think are missing, please let me
know - or better yet, if you're up for constructively adding them - go
ahead and do that.

Thanks,

Zeev

On Sat, Aug 10, 2019 at 6:21 PM guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:

1- How would you envision a shared runtime between PHP and P++, in the
case that this new evolved solution decides to support objects as keys
in array structure? This fundamentally changes internals, and a
drastic change to both runtime of PHP and P++ would be required.

Why would that only make it into P++ and not PHP? Things which are
sensible to both dialects should go into both dialects.

2- How would you envision injecting an actual namespace structure,

allowing scoping support for namespaces? FYI, this is what blocked me
to finish class visibility in https://github.com/php/php-src/pull/947
It'd require drastic changes in both PHP runtime and P++ too.

I don't think we have an answer for that, but I also think it's an
orthogonal question. It applies at the exact same way to the Editions.

The only I see this to operate is either P++ re-implementing the same

PHP structures in order to evolve, leading to a full fork becoming
more attractive, or compromises in P++ (like unable to support a given
feature) because PHP would make it set back.

While I think that the deltas would be a lot smaller than something we
should lose sleep over in terms of maintenance overhead - this will
primarily depend on the substance of what we'd want to change - and not on
how we package it. Whether we go for feature-specific declare()s,
Editions, or P++ - makes little to no impact on the complexity of the code
base. In fact, if anything - having an all-or-nothing option is likely to
make the engine code simpler to develop and maintain, as instead of a huge
number (per-feature) or medium number (Editions) of combinations that need
to be designed to work together, supported and tested - we'd have just two.

Do you view this differently?

Thanks for the feedback!

Zeev

There is a very vocal minority right now asking for BC breaking language changes who IMHO are a bit too quick dismissing opinions of very distinguished PHP developers.

I would just question the assertion that it's a vocal minority when
viewed in a wider context. In the realms of internals it may be, but
this discussion board represents at most a miniscule fraction of those
using PHP.

Outside of these walls, on the likes of reddit, discord and other
discussion mediums, it is my take that the majority seem to favour a
leaner, cleaner, stricter language, even at the cost of some backwards
compatibility. This is of course anecdotal, but I voted on a survey a
few days ago and just checked the results again just now, and it shows
the vast majority of people on that forum were in favour of pushing the
language at the cost of backwards compatibility. Prioritizing backwards
compatibility did not receive a strong response.

I seem to remember listening to Nikita on Derick's podcast a while ago
where he made comment on his observation that newer generation
programmers were looking for improved typing and strictness.

Mark Randall