Re: [PHP-DEV] P++: FAQ

[Chase Peeler]

On Fri, Aug 9, 2019 at 7:08 PM Larry Garfield 
wrote:

> On Fri, Aug 9, 2019, at 2:54 PM, Zeev Suraski 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 1 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 

Re: [PHP-DEV] P++: FAQ

[Larry Garfield]

On Fri, Aug 9, 2019, at 2:54 PM, Zeev Suraski 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 1 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.

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 

Re: [PHP-DEV] Re: P++: FAQ

[Sara Golemon]

On Fri, Aug 9, 2019 at 4:30 PM Zeev Suraski  wrote:

> In the spirit of my response to Bob, I added a new FAQ:  "How does this
> differ from Nikita's Editions idea?"
>
>
"""Related to rollout - the Editions approach doesn't allow for just two
dialects - but any number of dialects. We could have a PHP2020 dialect,
along with a PHP2022 dialect and a PHP2027 dialect. If we keep them all -
this may actually increase our maintenance complexity."""

I don't think we would keep them all.  We could set a sunset cycle for
dialects similar to branch support cycles.   PHP2020 comes out and we
support that along with PHP1996.  Two years later, we introduce PHP2022 and
we continue to support 2020 and 1996.  When PHP2024 comes out, we drop
PHP1996.  When PHP 2026 comes out, we drop PHP2020, etc

This does introduce a point where legacy apps must fix their code or simply
not upgrade, but it also provides a path to upgrade to latest support
version, then migrate files one at a time to that version's latest,
allowing an update to latest-latest.  This is significantly better than the
current state of syntax BC breaks which requires all updates to occur WITH
the upgrade.

Meanwhile, we have a little more work (work you and Niki are both
suggesting we take on already), but with a bounded cap on how long we carry
complications around.

-Sara

Re: [PHP-DEV] P++: FAQ

[Zeev Suraski]

On 10 Aug 2019, at 1:51, Sara Golemon mailto:poll...@php.net>> 
wrote:

On Fri, Aug 9, 2019 at 4:58 PM Zeev Suraski mailto:z...@php.net>> 
wrote:

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

That approach did occur to me to, but as I said in my earlier reply, I
don't think this actually addresses the goals set by the short tags removal
proposal *as I understand it*.  Maybe it does, but for example one could
still not start a file with "

Re: [PHP-DEV] P++: FAQ

[Sara Golemon]

On Fri, Aug 9, 2019 at 4:58 PM Zeev Suraski  wrote:

> 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  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).
>
> That approach did occur to me to, but as I said in my earlier reply, I
don't think this actually addresses the goals set by the short tags removal
proposal *as I understand it*.  Maybe it does, but for example one could
still not start a file with "

Re: [PHP-DEV] P++: FAQ

[Sara Golemon]

On Fri, Aug 9, 2019 at 4:30 PM Mark Randall  wrote:

> On 09/08/2019 22:02, Sara Golemon wrote:
> > 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().
>
> Or maybe a string from getType() and an object from getTypeAnnotation() ?


> 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.
>
> I don't see these (or Generics which you also mentioned) as being
inherently incompatible between more/less strict codebases.
Say we have an array or ValueObject in "more strict" code, we
could refer to an unspecialized version of that as merely "array" or
"ValueObject" in "less strict" code.  Or even not refer to its type at
all.  Without a formalized proposal for how these are implemented, I'm not
sure we can assume there will be technical challenges which we simply can't
overcome.

My point being, I'm not sure these things necessarily require a schism.  We
should be certain they do before we invest much time in figuring out the
how of it.

-Sara

Re: [PHP-DEV] P++: FAQ

[Zeev Suraski]

On Sat, Aug 10, 2019 at 12:03 AM Sara Golemon  wrote:

> On Fri, Aug 9, 2019 at 2:54 PM Zeev Suraski  wrote:
>
> > 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  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

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] P++: FAQ

[Midori Koçak]

I do completely agree with this and would like to be part of it. I am
really frustrated to see old developers shrug every time I talk about php.
I am enthusiastic about our language, the language I started coding with
and the language that evolved in years while I was learning it.

2 years ago, while I was preparing for facebook whiteboard interview for 6
months (I was not hired, I don't know what was the reason is.) I was
shocked to see while learning built in array and string functions naming
and parameter order. While we are advocating using coding standards,
forcing people to use PHP-FIG with different versions and advices, our
language does not have the same consistency, I know that was a must for
backwards compatibility with C, but makes me feel bad about the things I am
advocating for years.

Also, it is almost impossible for a newcomer to get into the internals. I
know that PHP source code is robust, evolved in many years to a position
that powers almost all of the internet but adding a new feature (which I
attempted once) requires a great C skill and familiarity with codebase
because of not having comments or source code documentation other than
internals book. (I also cannot say my attempts were welcomed with
happiness, which resulted me to lose my motivation, thankfully NCAO was
implemented by nikita popov)

I would really would be happy to see P++ to be built with some modern
compiled language like Rust and have nice guidelines and techniques to add
new features including new programming concepts. P++ should be the real
programming language of the future, should welcome newcomers, be easy to
use without bureaucracy of Java, nor encouraging spaghetti like code in
Python. I think PHP's secret is this, highly versatile, similar to a swiss
army knife, while other languages rant about their modernity and
superiority, it allows us to survive in the middle of the winter in a
forest under the storms. Even it is slow sometimes nor it is not perfect,
it's like me, it learns, it evolves, not perfect but it's the most used
language of the internet at the end.

>From a humanitarian perspective, we have a huge potential here to create
most diverse, most inclusive, most welcoming language and programming
culture in the times that women and minorities leave the industry because
of the unneeded ego atmosphere.

>From a technical perspective, P++ can be the language of the future and
bring peace to the galaxy.

Cheers,
Midori




On Fri, 9 Aug 2019 at 22:54, Zeev Suraski  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
>

Re: [PHP-DEV] P++: FAQ

[Mark Randall]

On 09/08/2019 22:02, Sara Golemon wrote:

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


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

Re: [PHP-DEV] Re: P++: FAQ

[Zeev Suraski]

On Fri, Aug 9, 2019 at 11:27 PM Mark Randall  wrote:

> On 09/08/2019 20:54, Zeev Suraski wrote:
> > It's available here:  https://wiki.php.net/pplusplus/faq
>
> I am now even more confused.
>
> How is this drastically different to Nikita's suggestion of setting a
> compiler version via rust-like version declares?
>

In the spirit of my response to Bob, I added a new FAQ:  "How does this
differ from Nikita's Editions idea?"

Zeev

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

[Arnold Daniels]

It seems that the only people in favor of making this split, either as a
fork, directive or otherwise, are the people that do not intend to switch
to this new flavor.

So why not the other way around, with a new flavor named "PHP classic"?
Those who do not want to participate in the progression of PHP can opt to
run PHP classic instead.

- Arnold

P.S. I'm not arguing that this, or any split is a good idea. In not even
arguing that this is a viable option. Instead, see it as an aid to help you
see things from the other side and understand why people are getting
emotional.

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

[Zeev Suraski]

Bob,

I appreciate your candid email.  Please see responses below.

On Fri, Aug 9, 2019 at 11:12 PM Bob Weinand  wrote:

> It's clearly quite a feat, your contributions to PHP 3 and PHP 4.
> This does not give you any authority now.


While I completely disagree, that is completely beside the point.  My
comments to Dan were not in the context of authority - but in the context
of knowledge.
I think it takes quite a bit of Chutzpah, to tell a person - that by his
widely-known credentials is an world-class expert with how the PHP engine
works - that he effectively doesn't know what he's talking about.  Even
more so when it's coming from someone who's no such expert.

>From my perspective at least (and others I've talked to), you are writing
> like you would have a leadership position which you do not have.


You're obviously entitled to that opinion.  But I'm entitled to my own.
PHP 7, which you're likely currently using - would not have existed if it
wasn't for my leadership (and, of course, Dmitry's remarkable skills, as
well as Nikita's and yours).


> Back to the main question:
> I think I have worked much more recently than you actively on this project
> and I can tell you that Dan is absolutely right here.
>

The fact you worked more recently on the project isn't really relevant
here.  The fundamentals of what it means to add a new mode to PHP haven't
changed since the days of PHP 4.  What I am proposing is not more
complicated to implement than Nikita's 'editions' idea.  Arguably - in the
long run - it's actually less complicated.  It's also not complicated in
absolute terms.  Provided you understand the idea itself.

At the very least there's an additional maintenance burden (let alone
> implementing everything we'd like to change).
>

Yes, there is.  But for code that's super stable and barely ever changes.
And I'll point out again - the very same maintenance overhead - and more -
exists in Nikita's idea.
The only legitimate point of concern - which Nikita alluded to, is the
implementing all (or most) of the compatibility-breaking changes in one go
may be too challenging with the resources we have.  My gut is that it
wouldn't be - although here I'd agree that Nikita's gut - or your gut for
that matter - are probably more accurately than mine.  With that said, we'd
only know that once we look at the list.

I'm not going to defend Dan's tone here, but let me agree with what he's
> saying.
>

I'm happy that you at least don't defend his tone.


> You are being divisive, intentionally or not (I assume the latter),
> whether you're aware or not.
>

It may surprise you, but I'm well aware of it.  I know that the majority of
internals@ frequenters (at least the ones who speak up) are from the
strict/no-BC camp, and having been a key proponent of the other school of
thought - that did not buy me much love on internals.  And yes, I know
there are other reasons.

However, I'm also well aware of the fact that while internals@ sets the
course for PHP - there are groups in PHP world which are grossly
underpresented in it (or aren't represented at all).  Trust me, I'm not
enjoying any of this.  You may think I'm getting some sort of a kick out of
having a 15-way discussion with folks attacking me from every direction.  I
don't, it's as pleasant as having my teeth pulled out.  Take Nikita's
comments re: his mental well-being, and multiply them twentyfold - and
you'd probably get an idea of my level of enjoyment is.  Others - who share
my view and have more code-contributions merit than almost everyone else
combined (I'm talking about Dmitry here), just don't have the mental
strength to deal with it and gave up.  But even if you don't think I have a
leadership position, as one of the people who started this project and
helped lead it to tremendous success  - and as someone who's well aware
that there's a much more diverse universe beyond internals@ - I refuse to
give in.  Even more so when I think there may be a way to solve our biggest
challenge over the last decade in an elegant way that works for everyone.

Let me, at this place, kindly ask you to not repeatedly engage in a same
> discussion. Have your voice heard, once.

There are a lot of topics where you state something (with content going
> also towards other tangents, discussing voting systems) and then the topic
> starts going off a tangent.
> This is annoying. I want to read the technical points. And then form my
> opinion. Not find long discussions about anything else or backs and forths
> not leading to any result or providing more technical context.
>

While I can't guarantee that I'll have my voice heard once (this is not, at
all, what a mailing list is about - it's about interactivity) - I can say
that I'll try to move to an article approach - like the Counterpoint I
published for short tags or the FAQ for P++.

Get a chat room to discuss process issues. Don't always be the one who
> presents the ideas. You ARE being viewed as controversial. You 

Re: [PHP-DEV] P++: FAQ

[Sara Golemon]

On Fri, Aug 9, 2019 at 2:54 PM Zeev Suraski  wrote:

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

1. Short open tags.  This is probably the ugliest nut to crack since it
can't even be guarded on a declare directive.  Adding a new open tag
doesn't really fix that though, it just changes the specific shape of the
problem.  Unless you add an INI for disabling PHP mode.

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.

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

4. Argument order/Naming consistency. I have little respect for this
complaint about PHP, but perhaps this is an assumed goal?  If it is, then
the reusability of the majority of the runtime comes into question since
anything we "fix" in P++ needs to have branching and/or multiple
implementations.

Am I *completely* off base?

-Sara

[PHP-DEV] Re: P++: FAQ

[Mark Randall]

On 09/08/2019 20:54, Zeev Suraski wrote:

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


I am now even more confused.

How is this drastically different to Nikita's suggestion of setting a 
compiler version via rust-like version declares?


It seems to me that it's just moving the version definition to a tag 
instead of a declare, and having a "Anything and everything new" version.


Is there a major difference I'm not immediately seeing?

Mark Randall

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

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

[Bob Weinand]

Hey Zeev,

> Am 09.08.2019 um 19:44 schrieb Zeev Suraski :
> 
> On Fri, Aug 9, 2019 at 7:44 PM Dan Ackroyd  wrote:
> 
>> On Fri, 9 Aug 2019 at 17:10, Zeev Suraski  wrote:
>>> 
>>> 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.
>> 
> 
> Before I move on, I have to say I admire your level of confidence.  I can
> only dream of having something even remotely close.
> 
> You're talking to a person that co-wrote the PHP engine, twice, that led
> parts of a 3rd engine rewrite, that helped lead (although at a hands-off
> manner) a 4th engine rewrite, that wrote OPcache, and a bunch of other
> things - and yet you still feel confident to tell me that I have no idea
> what I'm talking - when talking about precisely that.

It's clearly quite a feat, your contributions to PHP 3 and PHP 4.
This does not give you any authority now. You are not a current active code 
maintainer.
I won't deny you the respect for your former achievements - but as it is now, 
you are - not to sound harsh, but just stating the fact - a single person here 
with opinions (like we all).

From my perspective at least (and others I've talked to), you are writing like 
you would have a leadership position which you do not have.

I honestly think you should back off for some time. I definitely appreciate 
everyone sharing their opinions ... More on that below.

Back to the main question:
I think I have worked much more recently than you actively on this project and 
I can tell you that Dan is absolutely right here.

> If I were in your place, I'd be wondering "am I missing something?" and
> probably try to ask some clarifying questions before telling that other guy
> that he's clueless and/or lying.  Even if I disagreed with that person on
> virtually everything.

I cannot tell - I have no way to analyze your brain - it seems though, you are 
thinking to know more than you actually do.
Maybe it's wrong, maybe it's right. Dan is not necessarily trying to be 
disrespectful here, he just simply does not add the disclaimer "it seems to 
me". It is his perspective he is sharing, and I must say it overlaps with mine.

> With that out of the way - the very short version is that there's nothing
> mutually exclusive about these statements.  In fact, saying that means that
> you really do not understand what the idea is.  There could be several
> reasons for that - but I'm willing to take the blame as perhaps I didn't
> make it entirely clear.  I'll try to remedy that separately from this email.
> 
> 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 another illustration, an even clearer one - that you simply don't
> understand what the idea is at any meaningful level.  Here too - I'll take
> the blame.  I'm going to try and fix that.
> 
> This is not an appropriate thing to suggest.

At the very least there's an additional maintenance burden (let alone 
implementing everything we'd like to change).

>> 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.
>> 
> 
> Dan, don't get this the wrong way, but if anybody is behaving
> inappropriately, that would be you.  You repeatedly talk to me in a
> condescending (text) tone, you're virtually always interpreting my words in
> the most negative and malicious way possible (and beyond), and you don't
> shy away from doing that publicly.  You're being repeatedly disrespectful.
> 
> Adding
> 
>> cheers
> 
> at the end does not change that..
> 
> I don't address you in such a disrespectful manner, neither should you.
> Please stop.

I'm not going to defend Dan's tone here, but let me agree with what he's saying.
You are being divisive, intentionally or not (I assume the latter), whether 
you're aware or not.

Let me, at this place, kindly ask you to not repeatedly engage in a same 
discussion. Have your voice heard, once.
There are a lot of topics where you state something (with content going also 
towards other tangents, discussing voting systems) and then the topic starts 
going off a tangent.
This is annoying. I want to read the technical points. And then form my 
opinion. Not find long discussions about anything else or backs and forths not 
leading to any result or providing more technical context.

Get a chat room to discuss process issues. Don't always be the one who presents 
the ideas. You ARE being viewed as controversial. You bringing proposals up is 
not going to be a productive discussion.
Let others be your 

[PHP-DEV] P++: FAQ

[Zeev Suraski]

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

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

[Chase Peeler]

On Fri, Aug 9, 2019 at 3:02 AM Joe Watkins  wrote:

> 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
>
>
>
>
>
>
>
> On Fri, 9 Aug 2019 at 01:53, Mark Randall  wrote:
>
> > On 09/08/2019 00:08, Zeev Suraski wrote:
> > > 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 

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

[Zeev Suraski]

On Fri, Aug 9, 2019 at 7:44 PM Dan Ackroyd  wrote:

> On Fri, 9 Aug 2019 at 17:10, Zeev Suraski  wrote:
> >
> > 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.
>

Before I move on, I have to say I admire your level of confidence.  I can
only dream of having something even remotely close.

You're talking to a person that co-wrote the PHP engine, twice, that led
parts of a 3rd engine rewrite, that helped lead (although at a hands-off
manner) a 4th engine rewrite, that wrote OPcache, and a bunch of other
things - and yet you still feel confident to tell me that I have no idea
what I'm talking - when talking about precisely that.

If I were in your place, I'd be wondering "am I missing something?" and
probably try to ask some clarifying questions before telling that other guy
that he's clueless and/or lying.  Even if I disagreed with that person on
virtually everything.

With that out of the way - the very short version is that there's nothing
mutually exclusive about these statements.  In fact, saying that means that
you really do not understand what the idea is.  There could be several
reasons for that - but I'm willing to take the blame as perhaps I didn't
make it entirely clear.  I'll try to remedy that separately from this email.

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 another illustration, an even clearer one - that you simply don't
understand what the idea is at any meaningful level.  Here too - I'll take
the blame.  I'm going to try and fix that.

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

Dan, don't get this the wrong way, but if anybody is behaving
inappropriately, that would be you.  You repeatedly talk to me in a
condescending (text) tone, you're virtually always interpreting my words in
the most negative and malicious way possible (and beyond), and you don't
shy away from doing that publicly.  You're being repeatedly disrespectful.

Adding

> cheers

at the end does not change that..

I don't address you in such a disrespectful manner, neither should you.
Please stop.

Zeev

Re: [PHP-DEV] Improve visibility of RFC negative feedback

[Dan Ackroyd]

While I think there still might be a seed of a good idea here, I am
not going to pursue it at this time. I believe that it could be
misused to distract from productive conversations.

Before it can be discussed further,  the PHP project needs to have a
Code of Conduct to prevent people who are in sum being detrimental to
the project from being too distracting.

cheers
Dan
Ack

On Tue, 6 Aug 2019 at 22:54, James Gilliland  wrote:
>
>
>
> On Mon, Aug 5, 2019 at 8:34 AM Dan Ackroyd  wrote:
>>
>>
>> # Proposal - improve visibility of negative feedback
>>
>> When someone creates an RFC, near the top of that page they should
>> create a link to a separate page that will contain negative feedback.
>> People other that the RFC author are free to put whatever negative
>> feedback think is appropriate on that 'negative feedback' page.
>
>
> A kind of in the weeds question but would this require karma or just wiki 
> registration? Current discussions are pretty open on the list but karma would 
> lock down this part of the process a lot for better worse.

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

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

[Dan Ackroyd]

On Fri, 9 Aug 2019 at 17:10, Zeev Suraski  wrote:
>
> 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

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

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] Re: Bringing Peace to the Galaxy

[Zeev Suraski]

Sent from my tablet
> On 9 Aug 2019, at 19:02, Mark Randall  wrote:
> 
>> On 09/08/2019 08:15, Zeev Suraski wrote:
>> 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.

Regardless of whether or not it’d happen - this has nothing to do with the 
point at hand.  It’s not whether C and C++ are good or bad.  It’s about the 
concept of introducing a sister language that provides new capabilities and 
certain different behaviors, rather than changing the original one.

We’re not arguing whether PHP/P++ are good, we’re discussing whether it makes 
sense to introduce a sister language to PHP.

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

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

[Mark Randall]

On 09/08/2019 08:15, Zeev Suraski wrote:

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/


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

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] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Robert Korulczyk]

> Disabling short tags now is done with "an explicit directive" (there has to 
> be a specific ini file with a specific setting 'short_open_tag = 0'). 
> Isn't this the same "situation when you create a separate file with an 
> explicit directive"?

No, it's not. `php.ini` is outside of project responsibility - as a developer 
you don't really configure this in any way, your application does not
have any explicit directive to disable/enable short open tags. You just 
accidentally using feature that could lead to code leak.
In your example with `engine` directive you explicitly disable PHP engine by 
creating dedicated file for that purpose - there is no way do to this by
accident and then does not notice it.


> If a coder (or IDE) has written ' unless tested the effect (a part of code not being parsed/executed) will be
> exactly the same if the feature suddenly disappeared (unless the additional 
> checks in the 'v2 RFC' which on the other hand would make the engine a
> tiny bit slower but probably have to be implemented to avoid such accidents).

At least the this behavior will be consistent - you will not have cases when 
code works fine on one environment and leak on another.


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

[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] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Reinis Rozitis]

> This does not explain how someone could use that feature *by accident*. I gave
> an example where you can use short open tags by accident, and it is really 
> easy
> (the most popular IDE sometimes generates code with short open tags) and hard
> to notice (it is not easy to spot a difference between ` can
> you compare this to situation when you create a separate file with an explicit
> directive to disable PHP engine, and then be surprised that code is not 
> executed?

Disabling short tags now is done with "an explicit directive" (there has to be 
a specific ini file with a specific setting 'short_open_tag = 0'). 
Isn't this the same "situation when you create a separate file with an explicit 
directive"?

If a coder (or IDE) has written '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] Re: Bringing Peace to the Galaxy

[Mark Randall]

On 09/08/2019 08:15, Zeev Suraski wrote:

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

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Robert Korulczyk]

> I did mention such example with the 'engine' setting ( 
> https://www.php.net/manual/en/apache.configuration.php#ini.engine as it's 
> PHP_INI_ALL ). Of course you could ask why would anyone do that (and afaik 
> it's sapi specific) but technically it can happen just in one "hard to 
> notice" subdirectory/tree.

This does not explain how someone could use that feature *by accident*. I gave 
an example where you can use short open tags by accident, and it is
really easy (the most popular IDE sometimes generates code with short open 
tags) and hard to notice (it is not easy to spot a difference between `http://www.php.net/unsub.php

RE: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Reinis Rozitis]

> -Original Message-
> From: Robert Korulczyk [mailto:rob...@korulczyk.pl]
>
>
> Can you give an example where using `.user.ini` may create unexpected and hard
> to notice code leaks?

I did mention such example with the 'engine' setting ( 
https://www.php.net/manual/en/apache.configuration.php#ini.engine as it's 
PHP_INI_ALL ). Of course you could ask why would anyone do that (and afaik it's 
sapi specific) but technically it can happen just in one "hard to notice" 
subdirectory/tree.

Note that atm short_tags are by default enabled and the disable happens only in 
php(-cli).ini so unless one throws the ini configuration files around willy 
nilly it is a deliberate decision from administrator. 



p.s. to clarify I'm not against changing the default value to disabled (to be 
consistent with the distributed ini-examples and (coding) recommendations) but 
I still don't understand what is the reason to deny for end-users the ability 
to change/re-enable this feature if they need it and choose so.

But according to some emails for some reasons the existence of short tags now 
has turned out to be a major language future/feature blocker .. so go figure.

rr


--
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 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] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Robert Korulczyk]

> Argument for "only a particular code path in a particular environment" is 
> somewhat weak because in that case  why does even ' .user.ini' feature exists 
> (especially in apache sapi where you can even do engine = 0) as it also can 
> lead to wildly different language behaviour?

Can you give an example where using `.user.ini` may create unexpected and hard 
to notice code leaks?


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] Re: Bringing Peace to the Galaxy

[Zeev Suraski]

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

On Fri, Aug 9, 2019 at 10:02 AM Joe Watkins  wrote:

> 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
>
>
>
>
>
>
>
> On Fri, 9 Aug 2019 at 01:53, Mark Randall  wrote:
>
> > On 09/08/2019 00:08, Zeev Suraski wrote:
> > > 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 

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

[Zeev Suraski]

On Fri, Aug 9, 2019 at 2:53 AM Mark Randall  wrote:

> On 09/08/2019 00:08, Zeev Suraski wrote:
> > 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[]).
>

This might be exactly the point.
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.
In the same way that C developers would resist if someone tried to go on a
mission to convert them all to C++ developers - there's a big crowd in the
PHP space that would resist some (many) of the things you think are
absolutely awesome.  The thing is - both of you can be right at the same
time - as long as neither side is missionary about their position.

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


We *all* agree.  That's the 3rd thing I meant to write and forgot to ("I
want to state 3 things and ask another", followed by only 3 items :)).

IMO, long term, the former is greatly
> outweighed by the latter.
>

Here we don't all agree.  If the benefit is marginal to non-existent - than
even when multiplied across decades - it remains marginal to non existent.
That's why the position of the more BC-conscious crowd is that each BC
break needs to have a good case with tangible benefits.  It's always
relative - not absolute.

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'm actually not following what you're saying here, and would appreciate it
if you could further explain.
But even without entirely understanding what you meant - my guess is that
somewhat like C and C++ - these two flavors would cater to different people
and different projects.
Some frameworks are likely to embrace P++ and declare that their next
version is going to be based on that.  Others (such as Laravel, apparently)
are likely to state they want nothing of it, and would stick with dynamic
PHP for the long haul.
In turn - end users will also be able to choose whether they stick with PHP
for the long haul, keep their PHP investments and start using P++ for their
next project, or migrate entirely to P++.  All three are viable long term
options.  And with my approach - you can mix and match the two - so a PHP
app can use a P++ framework, a PHP app may expose a P++ plugin API, etc.

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

Passing these types of things across barriers will likely simply not make a
lot of sense.  It won't be a matter of it breaking - it'll simply not make
sense.  There'll likely be no issue calling PHP from P++;  And PHP code
will be exposing APIs using data types that it has, and not ones that it
doesn't.  Much like C++ developers often call into C (always, in fact,
either directly or indirectly)- that's not an issue at all.


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


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

Thanks 

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

[Joe Watkins]

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







On Fri, 9 Aug 2019 at 01:53, Mark Randall  wrote:

> On 09/08/2019 00:08, Zeev Suraski wrote:
> > 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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