[PHP-DEV] PHP 7.4.0beta2 is available for testing

[Derick Rethans]

PHP 7.4.0beta2 has just been released and can be downloaded from:



Or use the git tag: php-7.4.0beta2

Windows binaries are available at: 

Please test it carefully, and report any bugs in the bug system at
.

Hash values and PGP signatures can be found below or at
.

7.4.0beta3 should be expected in 2 weeks, i.e. on August 22nd, 2019.

Thank you, and happy testing!

Regards,
Peter Kokot & Derick Rethans

php-7.4.0beta2.tar.gz
SHA256 hash: 729fc7fcce7795a7162618806c2b3c2a9c2473a3b1e0c8f734daf3b8e522449e
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl1JJMMACgkQkQ3rRvU+
oxKeyg//XXRwkFB9MmwGTIs0QHw0NHr+Qyw+oH8nQnzFORUm1ZZWHBcJ4ghHFjjE
QzxNSeO4t9rjMEWHX8iRWzv+3xIoKvqlvlkRcGUp0JfDC5DE2q821erKPWM+rtxt
V1F2BX2rOAtchwrXuJnzR4d4WHEHDxvt4/m7j/SLlOnhIoeUtbBbAeNqO+H0gFSl
gYTi9dzboqk6ZnWxoB0WcFtQrJ6y6LpqhYd1Aum6xjHktQaCjuJbWyXyb9gRibzh
XjoyDzP54sUJVP/Ehgx5eKdCg3LC5zdMx1IaWXNwE1IDdXDJmJXQ3nztHCzoffRv
+evxGI0cfaEMIAUQX2mbrPgRxFNYW9XuMZDe04Z8Q2RPGOEeWlQ9bNXTsw+LIvOh
iXgnnD720zwuiYlfVnKqnaDzSRRHeTcCl/g3BU+gRd515feaplVgXMVb83jOPlgk
gQ6mzEOhREWu4phPeP7JxSnWukFMOD5JGb3MaNomeKWbpylqTVjobX7pw4QyqNuu
XqD3hhrgtbq4RsNrFyysFrsQ0bxyKMPTjjWKocPwoPhjNow3fdE+mxfTkso63/xv
XcWLwrl7rvbA1f1fYbdqxO7jV1Fzfg6gupauFR9iIqHDVyrAGeseOEld603oh4WW
BVJrZqaeePVgY3QXF6AfgDh+8hvupAywq6rck/Z5zuof5bpGPpg=
=rjzL
-END PGP SIGNATURE-

php-7.4.0beta2.tar.bz2
SHA256 hash: 2e138e3b6c51caaf74724091d23d9868f7f139907ac1ade39ad768d6ed56495d
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl1JJMgACgkQkQ3rRvU+
oxKytxAA4gQ7PdS1ytVNiHpoPgPVDMaQOINSpmlk2LHq70iaS9LGjq04TtCUw6RP
UF6NJle0/Kw5NEEqHIzuDp74I4zKeyOBM2FqKPQmro52KVkFIltCx9BpVZppHiC5
J9nWK75I7d8QMWo6RVMXje77TqiYwfr8MI0R5BM6ji2Tx9kwRrHHNBFsiFTNYf8N
fpKLwQUtwuTXuaNoebwYdElXTmeHSms3hV1mNM4qns3LitcD7w2uAaDjQ1/a774B
RCO1Leyi5iZcm3A1BPOQn+3Cw5PS/M/le30OCJu1QOob6i8T0taSzwUXwJx99Vh4
I2o9SktNfnWycXhSY7WW3oAGJAKjZDZmYgqML3EZSpMQOCUZ+Tiw492wbR9SIW+J
wPBQ7IE90P8OhMiyThmKO2+50hpLB8Spod5r9skyFGPduI1+iQ39kvHFuxKnX/r0
qrTJ8caY2sSRfHijJKJffzjFS2l7nHfb1XpFYz3zaYOC0jSKdKun5vWLUmO9CGz5
EZyk0Hwh1I6gIknL/7P92u4R7IfDZmcGqrS0CA9rVoU4HCaH2VNo4mMcScblhP7x
1Vb+ogLCltPlJGZZ/j90hp9APl9veb8DtXLSWaBHPkWxx3I52eyawmf8ATQaOy4S
zGQHOtvb+QKCaQwIUTn2HyRtqApmwqLR7gm+GEdVPgnnULFt4Zg=
=5UXf
-END PGP SIGNATURE-

php-7.4.0beta2.tar.xz
SHA256 hash: cb2c8734f0edfbc815bddfe5e56e959dbca493bcfe248d0213d27c5b95b4c4bc
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl1JJMgACgkQkQ3rRvU+
oxK4jg/+MZgITnEc/mARaAEufuhYiM7CZVAgTEI9hNn1mmXEbegixYah8EJoiBWn
AQzj49lnl+8cGvATnYDNI1w65/yZmSVq76598hFH6s+kV5kyqWhom3/NsOv2nww3
NTA+wMbRYxiq80OPU5iOLmda+79f1Naev12QesFHtWokYZ/ex+86nAa7P2gHV2/a
AtFJ/vL244PpmyQzV4oAZzgsLkqUBVjQf2L8FeW6iEno3CdIrMhQbmd3uCC9oKSH
ICmPcC1AV7QrTTWogvGofFF6AtsHmogefa8IcHftUzi8mCI4+7z3qksPExHh6EA0
chESxhVglEw7uCSyKphMyinUu6wDPnd8s60yMWWkDXeZEg7pxe+sJ6M7XVeN7jbl
UyMOZI3tXWbyb7EhRFHgSlw+ANxbxGc/HfWD7rGpJJ+R0Gr39G0AcE/EQeD2m4YL
wOnprhDDULzNStShb+eLiIJa6VAoL9QqRSWmcI3+y1LlMBPNSzQt4yxyPp1gsEjZ
tBQQjinMzGNgFmGV4PhMSiUeEw0cCT9zwgPga/NNRuFLknmKTn1gykfJoIHMFWf2
8Yd/G+QW1f4w3fnxIqz15P6J0R8wVGashc+rs18Aw+6HLOrvFMFOw0jwChn6huJ9
sXFsx5m5jTuavEiSgJwjlRPg573IJTyLt6ILl9Ew0JpWsA4gVnY=
=ogqR
-END PGP SIGNATURE-


-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io
Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
or become my Patron: https://www.patreon.com/derickr
twitter: @derickr and @xdebug

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

[Peter Kokot]

Hello,

On Thu, 8 Aug 2019 at 16:17, Chase Peeler  wrote:
>
> On Thu, Aug 8, 2019 at 9:35 AM Zeev Suraski  wrote:
>
> > On Thu, Aug 8, 2019 at 3:17 PM Brent  wrote:
> >
> > > I asked similar questions on Twitter, where Zeev replied the following:
> > > https://mobile.twitter.com/zeevs/status/115865658046464
> >
> >
> > I want to add a bit of color to this tweet:
> > - Estimated # of developers using PHP is at around 10M.  This is based on
> > some extrapolation from an EDS report from ~8 years ago that estimated that
> > number at >6M, and growth rates we've seen beforehand.
> > - Anecdotally, I've seen it used many times in non-distributable code over
> > the years - a lot more frequently than once per 100 users.
> > - Even if just 1% of the userbase uses short tags, that's ~100K.  We can
> > call this one a guess, but I'd say it's an educated guess that there's well
> > above 1% of the PHP userbase that uses short tags.
> >
> > It feels like much of the counter arguments are based on guesses without
> > > any real data to point to.
> >
> >
> > I wouldn't say they're guesses, but extrapolations - for instance, the fact
> > I'm aware of many PHP frameworks and apps, and am not aware of any single
> > one that allows short tags - makes me feel fairly comfortable to make the
> > statement that "virtually all frameworks and apps designed for public
> > consumption disallow short tags".  I can't preclude the possibility that
> > the fact that all of the apps and frameworks I'm aware of don't allow short
> > tags is a remarkable coincidence - or that there are countless ones I'm not
> > aware of that do allow short tags - but I think that my theory is a lot
> > more plausible.
> >
> > I work on an internal application. Even though portability is not a
> concern for anything we write, we haven't used short tags since it was
> rumored they were going to be removed in PHP 6 many years ago. That being
> said, this application has been in development since 2003. There is a large
> amount of legacy code written before I even started here, not to mention
> plenty of horrible code written after I did start in 2005 (this was my
> first job). As I mentioned in an email on this thread yesterday, most of
> our legacy code is "just leave it alone, it works" code. We are in the
> process of rewriting things, but, that takes time. We try and mess with the
> legacy code as little as possible. Something as simple as auto formatting
> with PhpStorm has broken things in the past - so I don't trust an automated
> tool to fix the short tags for me. Even if I'm the only person that has
> participated in this thread that has to maintain a codebase that consists
> of non-portable code with a large amount of short tags, that's still at
> least 1% of those that have participated in this thread, or one of its
> predecessors.
>
> Another thing to keep in mind is that most of the people writing and/or
> maintaining "non-portable" code probably don't work for a company in the
> software development industry. When I want to upgrade PHP, I have to
> convince our leadership of the value of me spending a couple of weeks
> fixing BC breaks. I have to show why that is more valuable than spending
> time on the development of new functionality. The more time required to do
> an upgrade, the more likely it will get punted to a future date.
>
> I'm not against BC breaks in general - they are a necessary evil. However,
> it's important that the negative impact of that break is far outweighed by
> the positive value it brings. I'll leave it up to each of you to determine
> how positive of an impact removing short tags would bring. I can promise
> you, though, that the negative impact would be VERY large. Just because you
> don't personally have to maintain any code that uses short tags doesn't
> mean that there aren't other developers out there that do. Every BC break
> is going to lead to a subset of users that will decide to not upgrade as a
> result. It will also lead to a subset of users that will decide to use a
> different technology (node, .NET, python, etc.) going forward. Many BC
> breaks are worth that risk. Is this one of them?
>
> Many people have talked about the potential impacts of keeping short tags.
> I have yet to see anyone give an actual example where they have been
> negatively impacted by their existence. I've given you my personal story of
> how removing them will negatively impact my company. I welcome anyone that
> can provide an actual incident where the existence of short tags hurt them,
> or, the continued existence is likely to have a large negative impact on
> them in the future.
>
>
> > Zeev
> >
>
>
> --
> Chase Peeler
> chasepee...@gmail.com

Thanks for sharing your stories about issues. Maybe we should start
also thinking about the impact on the language attractiveness to pick
it when starting a new web project since the core people can't come to
conclusions how to make the language more consistent on the long run

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

[Thomas Hruska]

On 8/8/2019 3:26 AM, Côme Chilliet wrote:

Le mercredi 7 août 2019, 15:57:02 CEST Chase Peeler a écrit :

Pretty much everyone (if not actually
everyone) that is against this RFC has stated that they don't actually use
short tags, and do not advocate that anyone else use them either.


This is what bugs me, the counter argument page from Zeev states «I never use 
short tags in any PHP code that I write, and as far as I recall - I never have. 
»,
  and at the same time «put hundreds of thousands of people through additional 
pain when upgrading.»

Is there any data that support the theory that hundreds of thousands of people 
use short tags?

Did anyone in this discussion stated that he was using them?



I used to use them extensively right up until the first RFC passed (e.g. 
CLI scripts, personal web apps, and some production systems).  Had 
several thousand references to resolve but I'm off them now, whichever 
way this second RFC round goes.  Other people chimed in that they use 
them too in "legacy production systems."


Open source userland development demands the long open tag.  So any 
scans of open source, public repos is going to be skewed heavily against 
actual use of short open tags.  You simply can't rely on Composer or 
GitHub stats to show real-world usage numbers in this instance.


So, yeah, people use them.

Also, just because a lawyer, a lobbyist, or an ambassador are themselves 
unaffected by some issue doesn't mean they can't represent a class of an 
underserved population to bring forth awareness, justice, or action.  In 
many cases, they are in better positions with sufficient contacts to 
reach the right people to bring forth such things that would otherwise 
never come to light.


--
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you will find useful.

http://cubiclesoft.com/

And once you find my software useful:

http://cubiclesoft.com/donate/

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

[Arvids Godjuks]

чт, 8 авг. 2019 г. в 17:56, Robert Korulczyk :

> > Many people have talked about the potential impacts of keeping short
> tags.
> > I have yet to see anyone give an actual example where they have been
> > negatively impacted by their existence. I've given you my personal story
> of
> > how removing them will negatively impact my company. I welcome anyone
> that
> > can provide an actual incident where the existence of short tags hurt
> them,
> > or, the continued existence is likely to have a large negative impact on
> > them in the future.
>
> I was bitten by short open tags. Despite the "no short open tag" policy in
> our app, one occurrence of ` email template so it was quite hard to notice on production. Especially
> that short open tags were disabled only on CLI, so we had code leak only in
> emails sent by cron. It took over a month to notice that bug.
>
> You may be concerned about people abandoning PHP due to BC breaks, I'm
> more concerned about people abandoning PHP because of issues like this. It
> gives me the impression that the language wants to hurt you...
>
>
> Regards,
> Robert Korulczyk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I'd say this is not really a language concern and more tooling and testing
problem. It's a class of a genuine mistake everybody does from time to time
- be it wrong PHP tag, HTML tag or closing } added on the wrong line
resulting in a logical error.
-- 
Arvīds Godjuks

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

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

[Rowan Collins]

On Thu, 8 Aug 2019 at 16:18, Arvids Godjuks 
wrote:

> BC is great, but you need to pull the cord at some point. And the whole
> short tag back and forth, with deprecation warning and stuff, has been
> around for last half a decade. It is time to accept that it needs to go
>


That's like saying from now on we should mandate PSR-2 indenting style in
the compiler, to stop people arguing about code formatting. Just because
people keep saying something, doesn't make it right.



> If the old guard starts to push back as much as I have seen here, we are
> going to lose momentum as a community and have people not willing to work
> on PHP as much.
>


I feel like the opposite: if people volunteering their time find that all
their energy is spent on pointless arguments about removing working
features, and none of it is spent on actually innovating the language,
they'll spend it somewhere else.



> Long story short - indecision is not an option.



Here's a decision for you then: short tags are fine how they are, and we
can stop wasting energy talking about them and get on with doing something
that actually benefits the language. That's not indecision, that's a
concrete position we could take to prioritise our efforts on something more
productive.


The previous RFC has
> passed. Everyone involved, I hope, understands that yes, there will be
> stuff going wrong for some users who are careless and/or ignorant and live
> under a rock. Can we really do anything about that?



Yes. Yes, we can. We can do what's proposed in the v2 RFC, or we can
reverse our decision. An RFC passing isn't a pact with the devil.



> Let's look into the future, use a reasonable amount of caution and/or
> deprecation notice periods, but please stop trying to block features
>


What is the feature being blocked if we leave short tags in PHP? If such a
feature existed, I would understand your frustration - but if it did, the
RFC could make the case for why adding that new feature was worth the pain
caused by removing the old feature. Since there is no such feature, there
is no such justification in the RFC, which is why it's so controversial.

Regards,
-- 
Rowan Collins
[IMSoP]

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

[Chase Peeler]

On Thu, Aug 8, 2019 at 11:18 AM Arvids Godjuks 
wrote:

> чт, 8 авг. 2019 г. в 16:42, Peter Kokot :
>
>> Hello,
>> Thanks for sharing your stories about issues. Maybe we should start
>> also thinking about the impact on the language attractiveness to pick
>> it when starting a new web project since the core people can't come to
>> conclusions how to make the language more consistent on the long run
>> (PHP 9 etc)... With more and more ambiguities, inconsistencies,
>> lockups, and dead ends behind the language there is probably also a
>> bit of a factor to consider that it lowers this attractiveness.
>> Meaning less people will think of adopting it (with all the things
>> combined - short tags, that and that inconsistency not being removed
>> from PHP due to major disastrous BC break there and there). So, the
>> damage is also on the long run with more and more locks and dead ends
>> not being able to be fixed and cleaned.
>>
>>
>> --
>> Peter Kokot
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
> Hello.
>
> Peter above put my thoughts perfectly.
>
> BC is great, but you need to pull the cord at some point. And the whole
> short tag back and forth, with deprecation warning and stuff, has been
> around for last half a decade. It is time to accept that it needs to go and
> there should be no runtime dependent switch for this. Valid PHP tags are
> ` I really liked how language picked up the cleanup pace in the last few
> years and it needs it. I finally see genuine interest in people to actually
> either come back or pick it up instead of JavaScript (NodeJS) and other
> fancy new shiny stuff. And a lot of it is because of the cleanup efforts
> and WTF?! removal, the language having the option to be stricter (I was not
> a fan of strict mode when it was coming up - now I don't use anything else
> - it is AWESOME).
> If the old guard starts to push back as much as I have seen here, we are
> going to lose momentum as a community and have people not willing to work
> on PHP as much. I mean anyone who has been on this list for more than 10
> years should remember how it was in 5.0-5.4 days - slow, painful and
> somewhat unfriendly, until a few major contributors kind'a muddled though
> and pushed a few major changes that allowed the momentum to build up and
> somewhat break the stalemate (and it did help that HHVM reared it's head
> and had stroked a few egos the wrong way). I guess the curve repeats
> itself, but we should make an effort to curb it and not revert back to "BC,
> BC, BC" holding everything up.
>
> Wait, how could positive progress have been made while short tags still
existed?


> Reality is, a lot of those "non-tech company" examples people give here
> has nothing to do with language evolution. Yes, they are users, but we are
> not responsible for the code they write, for the way they configure their
> web servers and the way they can run a PHP4 server past 10 years and still
> have no clue, because nobody cares or "it works, it makes money, no need to
> invest". I would say that most of us on this list, if not everyone, are
> smart enough to run/leave/not work for companies like that, so we are
> somewhat shielded from that ignorance and just forget how bad it can be.
>
> Long story short - indecision is not an option. The previous RFC has
> passed. Everyone involved, I hope, understands that yes, there will be
> stuff going wrong for some users who are careless and/or ignorant and live
> under a rock. Can we really do anything about that? I would say no unless
> we freeze the language and do nothing. I mean I have exposed my PHP code
> during server setup by just forgetting to do `systemctl reload nginx`,
> hitting the URL and getting my `index.php` on the screen more times than I
> care to confess to.
>
You're in the "all or nothing" logical fallacy. You are acting as if being
against the removal of short tags is the same as being against any BC break
at all. As we've said MANY times, BC breaks aren't the issue. THIS
PARTICULAR BC BREAK IS THE ISSUE. It provides little to no positives to the
users and does very little, if anything, to improve the language. At the
same time it WILL lead to a very big barrier in terms of the ability to
upgrade for a large number of users.



> Let's look into the future, use a reasonable amount of caution and/or
> deprecation notice periods, but please stop trying to block features
> "because stupid users". You give them the most secure software you can
> write, they go change settings on their own and get p0wned/defaced/hacked
> anyway even when you tell them not to do it and that y'r refusing to work
> on their project because of decisions they make.
>
> Actually, most BC breaks, including this one, seem to be focused on
preventing issues from "stupid users." We're saying that short tags are bad
because of reasons. We can't trust users to not use short tags as long as
they exist, 

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

[Robert Korulczyk]

> I'd say this is not really a language concern and more tooling and testing 
> problem. It's a class of a genuine mistake everybody does from time to time
> - be it wrong PHP tag, HTML tag or closing } added on the wrong line 
> resulting in a logical error.

This is a direct consequence of the language having settings that cause the 
same code to be interpreted (and works perfectly fine) in one environment
and be displayed in other (without any warning). This is not the same as a typo 
in HTML tag or logical error in code. This is literally a tool for
shooting yourself in the foot - it exists, but no one should use it.

And it is still really easy to use it by accident. For example, this is what 
PhpStorm generates when you try to inline-comment tag with short echo:




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

[Chase Peeler]

On Thu, Aug 8, 2019 at 10:42 AM Peter Kokot  wrote:

> Hello,
>
> On Thu, 8 Aug 2019 at 16:17, Chase Peeler  wrote:
> >
> > On Thu, Aug 8, 2019 at 9:35 AM Zeev Suraski  wrote:
> >
> > > On Thu, Aug 8, 2019 at 3:17 PM Brent  wrote:
> > >
> > > > I asked similar questions on Twitter, where Zeev replied the
> following:
> > > > https://mobile.twitter.com/zeevs/status/115865658046464
> > >
> > >
> > > I want to add a bit of color to this tweet:
> > > - Estimated # of developers using PHP is at around 10M.  This is based
> on
> > > some extrapolation from an EDS report from ~8 years ago that estimated
> that
> > > number at >6M, and growth rates we've seen beforehand.
> > > - Anecdotally, I've seen it used many times in non-distributable code
> over
> > > the years - a lot more frequently than once per 100 users.
> > > - Even if just 1% of the userbase uses short tags, that's ~100K.  We
> can
> > > call this one a guess, but I'd say it's an educated guess that there's
> well
> > > above 1% of the PHP userbase that uses short tags.
> > >
> > > It feels like much of the counter arguments are based on guesses
> without
> > > > any real data to point to.
> > >
> > >
> > > I wouldn't say they're guesses, but extrapolations - for instance, the
> fact
> > > I'm aware of many PHP frameworks and apps, and am not aware of any
> single
> > > one that allows short tags - makes me feel fairly comfortable to make
> the
> > > statement that "virtually all frameworks and apps designed for public
> > > consumption disallow short tags".  I can't preclude the possibility
> that
> > > the fact that all of the apps and frameworks I'm aware of don't allow
> short
> > > tags is a remarkable coincidence - or that there are countless ones
> I'm not
> > > aware of that do allow short tags - but I think that my theory is a lot
> > > more plausible.
> > >
> > > I work on an internal application. Even though portability is not a
> > concern for anything we write, we haven't used short tags since it was
> > rumored they were going to be removed in PHP 6 many years ago. That being
> > said, this application has been in development since 2003. There is a
> large
> > amount of legacy code written before I even started here, not to mention
> > plenty of horrible code written after I did start in 2005 (this was my
> > first job). As I mentioned in an email on this thread yesterday, most of
> > our legacy code is "just leave it alone, it works" code. We are in the
> > process of rewriting things, but, that takes time. We try and mess with
> the
> > legacy code as little as possible. Something as simple as auto formatting
> > with PhpStorm has broken things in the past - so I don't trust an
> automated
> > tool to fix the short tags for me. Even if I'm the only person that has
> > participated in this thread that has to maintain a codebase that consists
> > of non-portable code with a large amount of short tags, that's still at
> > least 1% of those that have participated in this thread, or one of its
> > predecessors.
> >
> > Another thing to keep in mind is that most of the people writing and/or
> > maintaining "non-portable" code probably don't work for a company in the
> > software development industry. When I want to upgrade PHP, I have to
> > convince our leadership of the value of me spending a couple of weeks
> > fixing BC breaks. I have to show why that is more valuable than spending
> > time on the development of new functionality. The more time required to
> do
> > an upgrade, the more likely it will get punted to a future date.
> >
> > I'm not against BC breaks in general - they are a necessary evil.
> However,
> > it's important that the negative impact of that break is far outweighed
> by
> > the positive value it brings. I'll leave it up to each of you to
> determine
> > how positive of an impact removing short tags would bring. I can promise
> > you, though, that the negative impact would be VERY large. Just because
> you
> > don't personally have to maintain any code that uses short tags doesn't
> > mean that there aren't other developers out there that do. Every BC break
> > is going to lead to a subset of users that will decide to not upgrade as
> a
> > result. It will also lead to a subset of users that will decide to use a
> > different technology (node, .NET, python, etc.) going forward. Many BC
> > breaks are worth that risk. Is this one of them?
> >
> > Many people have talked about the potential impacts of keeping short
> tags.
> > I have yet to see anyone give an actual example where they have been
> > negatively impacted by their existence. I've given you my personal story
> of
> > how removing them will negatively impact my company. I welcome anyone
> that
> > can provide an actual incident where the existence of short tags hurt
> them,
> > or, the continued existence is likely to have a large negative impact on
> > them in the future.
> >
> >
> > > Zeev
> > >
> >
> >
> > --
> > Chase Peeler
> > 

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

[Arvids Godjuks]

чт, 8 авг. 2019 г. в 17:57, Peter Bowyer :

>
>
> On Thu, 8 Aug 2019 at 16:18, Arvids Godjuks 
> wrote:
>
>> I really liked how language picked up the cleanup pace in the last few
>> years and it needs it. I finally see genuine interest in people to
>> actually
>> either come back or pick it up instead of JavaScript (NodeJS) and other
>> fancy new shiny stuff. And a lot of it is because of the cleanup efforts
>> and WTF?! removal, the language having the option to be stricter
>>
>
> Are you sure assigning this interest to cleanup efforts is not a
> correlation without causation?
>
> Other reasons interest in PHP can be growing:
> 1. We've got better libraries, frameworks and tooling in userland PHP than
> we used to have.
> 2. The hype cycle is wearing off NodeJS
> 3. people are slowly letting go of their outdated memories of what writing
> PHP / PHP code written by inexperienced programmers was like
>
> Peter
>

Everything is a contributor obviously, but in my personal experience the
one that really makes waves is when I tell people about "strict_types" and
"type hints". That really shocks people and make them look at 7.1+ with a
completely different attitude.

I mean I'm not claiming this is statistically sound data of a wide slice of
PHP users, but I do know quite a lot of somewhat closeted PHP developers
who do not show any public activity and just silently consume PHP and I'm
reluctantly playing the role of news gateway on what's new in PHP world. I
encouraged a few for years to move to better companies cause they were
stuck in a dead-end and just did not knew what is out there. No amount of
keeping the BC would make migrations to new versions in those environments
an easy task - stuff always broke, always in production, because devs had
no say or sometimes even did not know they are upgrading after the fact.

This is why I do not like excessive keeping of BC - there will always going
to be users like that, even major users, whom you do not suspect, but it is
a cl***k behind the scenes and that user can do 9-10 digit turnover a year.
Proper announcements, proper depreciation period, documentation update and
strong upgrade node message should cover everyone who is ready to listen
and understand. There are multiple tools to do short tag to long tar
conversion in bulk. I thought it was agreed years ago that runtime switches
that affect engine behaviour in a major way were bad and should be
eventually removed. And portable code version is using `https://t.me/psihius

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

[Zeev Suraski]

On Thu, Aug 8, 2019 at 9:10 PM Bishop Bettini  wrote:

> On Tue, Aug 6, 2019 at 7:34 AM G. P. B.  wrote:
>
> > The voting for the "Deprecate short open tags, again" [1] RFC has begun.
> > It is expected to last two (2) weeks until 2019-08-20.
> >
> > A counter argument to this RFC is available at
> > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags
> >
> > Best regards
> >
> > George P. Banyard
> >
> > [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2
>
>  when Facebook's source code leaked precisely because of this [1]?
>

Where's the evidence that it was precisely or even remotely because of
this?  Literally all of the PHP code leaks I've come across over the years
had to do with a misconfigured Web server - e.g., load Apache without
properly setting up handling for .php files, or having things like .inc
files not blocked from HTTP access.
As we deprecate short_tags, should we consider deprecating all SAPIs, and
roll our own high-performance Web server into PHP?  That's the only way to
truly do away with the main vector for PHP source code leakage.


>
> Much has been said about this being a "portability" issue. I think that's
> overly specific. The core issue is "fallibility". You can globally
> configure the language to stop recognizing itself as a language. That's
> weird and unexpected. So much so, that no one gives due thought to this,
> and we end up with security disasters.
>

Except these are so uncommon and rare (I'm not aware of a single one, which
doesn't mean there weren't any - but that they're not very common at all),
that perhaps, just perhaps, it's a bit of an exaggeration to present them
as a clear and present danger.

PHP.net has opined, for years, that  It's time to act. So much
> else breaks at the 8.0 boundary, let's do it all at once.


The "we're breaking things so badly anyway, let's break'm some more"
argument has been refuted many times on this list.  First, I don't think
we're breaking anything really badly in PHP 8.  And secondly, this remains
as bad a reason as it's ever been to break stuff.

Breakage is not binary - it accumulates.  The more you have of it - the
more difficult it is to migrate, and the slower is the migration.


> If anyone needs
> to justify the effort, let them say "

It's a security hole in the exact same level that httpd.conf is a security
hole.  Yes, misconfiguring your Web server can have severe consequences.
Thankfully, it's not nearly that big of a Thing for us to be concerned
about.

Zeev

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

[Nikita Popov]

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

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

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

[Mark Randall]

On 08/08/2019 21:17, Zeev Suraski wrote:

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


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


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


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


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


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


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


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


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

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


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


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


Mark Randall


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

[Zeev Suraski]

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

>
>
> On Thu, Aug 8, 2019 at 9:10 PM Bishop Bettini  wrote:
>
>> On Tue, Aug 6, 2019 at 7:34 AM G. P. B.  wrote:
>>
>> > The voting for the "Deprecate short open tags, again" [1] RFC has begun.
>> > It is expected to last two (2) weeks until 2019-08-20.
>> >
>> > A counter argument to this RFC is available at
>> > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags
>> >
>> > Best regards
>> >
>> > George P. Banyard
>> >
>> > [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2
>>
>> > when Facebook's source code leaked precisely because of this [1]?
>>
>
> Where's the evidence that it was precisely or even remotely because of
> this?
>

I'd like to add that looking at the source code[1] from the leaks, it
appears to be using long tags - which means that if it is authentic - short
tags were not the source of the leak.
Also, there was a Perl leak[2] from Facebook as well.  It's a bit difficult
to blame short tags for that one.

Zeev

[1] https://gist.github.com/nikcub/3833406
[2] https://gist.github.com/philfreo/7257723

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

[Zeev Suraski]

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

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

I think it's similar, but not quite the same, at least as far as what I
understood from what you were saying on that thread (I just reread it).
First, I think it's important we don't only focus on what we're going to
change - but also on what we're going to keep.  The motivation should not
be slow eventual migration from one codebase to another.  We would have
two, long-term supported codebases - a lot closer to C and C++ than to
different editions of a single language.  The distance between them would
be quite substantial from the get-go - and will likely grow farther as time
goes by, similarly to the situation with C and C++.

Also - I think that we should do our very best to get this "P++" right the
first time, as opposed to iterate on it and release editions that provide a
steady stream of change and breakage.  Of course - we can add new features
and evolve existing ones - but this should be a lot more similar to the
mini versions / feature releases we currently have.

It's certainly similar in concept, but not quite the same.

Zeev

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

[Bishop Bettini]

On Tue, Aug 6, 2019 at 7:34 AM G. P. B.  wrote:

> The voting for the "Deprecate short open tags, again" [1] RFC has begun.
> It is expected to last two (2) weeks until 2019-08-20.
>
> A counter argument to this RFC is available at
> https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags
>
> Best regards
>
> George P. Banyard
>
> [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2


I voted "yes" for removal. https://techcrunch.com/2007/08/11/facebook-source-code-leaked/
[2]:https://www.php.net/manual/en/language.basic-syntax.phptags.php

[PHP-DEV] Bringing Peace to the Galaxy

[Zeev Suraski]

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

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

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

At the other end of the spectrum, we have folks who think that we should
retain the strong bias for downwards compatibility we always had, that PHP
isn't in dire need of an overhauling repair and that as far as features go
- less is more - and we don't have to race to replicate features from other
languages - but rather opt for keeping PHP simple.

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

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

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

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

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

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

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

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

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

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

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

But more importantly - we could make much more radical changes a lot more
quickly.  Since migration 

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

[Chase Peeler]

On Thu, Aug 8, 2019 at 3:35 PM Zeev Suraski  wrote:

> On Thu, Aug 8, 2019 at 9:10 PM Bishop Bettini  wrote:
>
> > On Tue, Aug 6, 2019 at 7:34 AM G. P. B. 
> wrote:
> >
> > > The voting for the "Deprecate short open tags, again" [1] RFC has
> begun.
> > > It is expected to last two (2) weeks until 2019-08-20.
> > >
> > > A counter argument to this RFC is available at
> > > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags
> > >
> > > Best regards
> > >
> > > George P. Banyard
> > >
> > > [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2
> >
> >  2007
> > when Facebook's source code leaked precisely because of this [1]?
> >
>
> Where's the evidence that it was precisely or even remotely because of
> this?  Literally all of the PHP code leaks I've come across over the years
> had to do with a misconfigured Web server - e.g., load Apache without
> properly setting up handling for .php files, or having things like .inc
> files not blocked from HTTP access.
> As we deprecate short_tags, should we consider deprecating all SAPIs, and
> roll our own high-performance Web server into PHP?  That's the only way to
> truly do away with the main vector for PHP source code leakage.
>
>
> >
> > Much has been said about this being a "portability" issue. I think that's
> > overly specific. The core issue is "fallibility". You can globally
> > configure the language to stop recognizing itself as a language. That's
> > weird and unexpected. So much so, that no one gives due thought to this,
> > and we end up with security disasters.
> >
>
> Except these are so uncommon and rare (I'm not aware of a single one, which
> doesn't mean there weren't any - but that they're not very common at all),
> that perhaps, just perhaps, it's a bit of an exaggeration to present them
> as a clear and present danger.
>
> PHP.net has opined, for years, that 
>
> This is the opinion of the person who wrote this document.  I'm sure many
> agree with him - but there's no person named 'PHP.net' that can opine on
> things.
> That said - if you think people read the manual and are aware that this is
> discouraged and act accordingly - it's all the more reason to not care
> about this issue.  If they don't, well, then it doesn't mean much that it's
> written over there.  I personally don't think too many people read the
> manual on PHP's opening tags (I have absolutely no data to back this gut
> feeling up - it's just my gut feel).
>
>
> > It's time to act. So much
> > else breaks at the 8.0 boundary, let's do it all at once.
>
>
> The "we're breaking things so badly anyway, let's break'm some more"
> argument has been refuted many times on this list.  First, I don't think
> we're breaking anything really badly in PHP 8.  And secondly, this remains
> as bad a reason as it's ever been to break stuff.
>
> Breakage is not binary - it accumulates.  The more you have of it - the
> more difficult it is to migrate, and the slower is the migration.
>
>
> > If anyone needs
> > to justify the effort, let them say " >
>
> It's a security hole in the exact same level that httpd.conf is a security
> hole.  Yes, misconfiguring your Web server can have severe consequences.
> Thankfully, it's not nearly that big of a Thing for us to be concerned
> about.
>
> We need to get rid of the display_errors ini directive as well. It
definitely shouldn't default to "1" or be set to "1" in the sample files
distributed with PHP. I would think this is a much greater security risk
than short tags. While we're at it, we need to get rid of the ability to
even set custom error handlers. If a programmer doesn't use that correctly,
they could still end up exposing error messages that contain sensitive
data.


> Zeev
>


-- 
Chase Peeler
chasepee...@gmail.com

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

[Nikita Popov]

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

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

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

[Zeev Suraski]

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

> On Thu, Aug 8, 2019 at 11:02 PM Nikita Popov  wrote:
>
>> On Thu, Aug 8, 2019 at 10:17 PM Zeev Suraski  wrote:
>>
>> This is basically what I have been advocating for a while now already,
>> somewhat hidden between all the other noise of the "namespace-scoped
>> declares" thread. The model I would like to follow are Rust editions (
>> https://doc.rust-lang.org/
>> 
>> edition-guide/editions/index.html
>> ). In PHP
>> right now, the way to do this technically would be based on a
>> declare(edition=2020) in every file. I was hoping to make this a
>> per-package declaration instead, but haven't found the perfect way to do
>> this right now.
>>
>> I think that introducing this kind of concept for PHP is very, very
>> important. We have a long list of issues that we cannot address due to
>> backwards compatibility constraints and will never be able to address, on
>> any timescale, without having the ability of opt-in migration.
>>
>> I do plan to create an RFC on this topic.
>>
>
> After reading your mail again, I think what I have in mind is maybe quite
> different from what you have in mind after all, even if the motivation and
> purpose (language evolution without breaking legacy code) is the same.
>

I'd describe my motivations quite differently than that.

First, I want to point out that my very first motivation was in fact a
human one - hence the subject line.  I think there's substantial value in
finding a solution for the constant contention on internals, without
neither camp giving up on their principals and beliefs.

Secondly - the current language-base of PHP (7.x) won't be 'legacy'.  I
think there's going to be a lot of new code written in it, and I think a
lot of people would prefer it over P++ - even in 5 or 10 years.  Again,
C/C++ is a very good analogy here.  If one camp remains 'missionary' about
forcing the other camp to assimilate as the long term goal - that's not at
all what I'm talking about.  This is also why an edition named 'PHP2020' is
somewhat problematic - as it implies you're behind if you're not using it.

My goal is to have two sister languages, with both PHP and P++ being equal
among equals, and not PHP being the 'dead language walking' and P++ being
the end goal of everything.

In particular, you seem to have a pretty strong focus on introducing a
> "new" language with a new name that just happens to interoperate with PHP.
>

Not quite - it doesn't just happen to interoperate with PHP.  It shares the
same runtime;  It shares the same extensions;  It shares many of the same
tools;  And most importantly - it's very similar in its syntax.  Again,
here too, the C/C++ analogy works really well.  Would you say C++ is a new
language that just happens to interoperate with C?  It's obviously a lot
more than that.

I don't think that's a direction we should be going down.
>

Oh well :|


> One of the larger issues with that is that it only works once: You have
> one BC break point going between PHP and PHP++, but that's it. Unless you
> want to rebrand your language every five years ;) What we need is something
> that is sustainable in the long term.
>

I think that the one, big-scoped compatibility breakage is a feature, not a
bug.  At the risk of sounding like a broken record - the C/C++ analogy
works well here too, this time specifically C++.  You can evolve the new
language - even substantially - but C++ always stayed C++ and C always
stayed C.  Yes, there's C++03, C++11, etc. - but at the end of the day -
the language is C++, and these editions are similar to the evolution we
introduce in feature releases.  If your goal is to have major BC breaks
every five years, then I doubt we can find common grounds.  But I'm not
sure how many folks here think that's a good idea either.  There's a big
gap between thinking we should break away from 20+ year old chains that are
they're fundamentally unhappy about, and moving to a 'let's redo the
language every five years'.


> I also don't like the idea of rebranding as a new language. While PHP has
> a bad reputation, I really don't think that introducing PHP++ will do
> anything positive to that. PHP should stay PHP. The core language should
> remain the same across all editions/epochs/whatever -- just with the
> possibility of addressing specific issues. As discussed in a recent thread,
> a new edition could require & annotations at call-sites and gain all the
> benefits that entails without breaking the ecosystem.
>

I'm sorry to hear that.  In this particular case I really think you're
wrong (FWIW) - rebranding can actually do a lot of positive things. It can
stir interest.  It can result in articles being written.  It can make
developers, development leaders and companies who have ruled out PHP
reconsider their decision since "this is no longer PHP".  A new version 

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

[Arvids Godjuks]

чт, 8 авг. 2019 г. в 16:42, Peter Kokot :

> Hello,
> Thanks for sharing your stories about issues. Maybe we should start
> also thinking about the impact on the language attractiveness to pick
> it when starting a new web project since the core people can't come to
> conclusions how to make the language more consistent on the long run
> (PHP 9 etc)... With more and more ambiguities, inconsistencies,
> lockups, and dead ends behind the language there is probably also a
> bit of a factor to consider that it lowers this attractiveness.
> Meaning less people will think of adopting it (with all the things
> combined - short tags, that and that inconsistency not being removed
> from PHP due to major disastrous BC break there and there). So, the
> damage is also on the long run with more and more locks and dead ends
> not being able to be fixed and cleaned.
>
>
> --
> Peter Kokot
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Hello.

Peter above put my thoughts perfectly.

BC is great, but you need to pull the cord at some point. And the whole
short tag back and forth, with deprecation warning and stuff, has been
around for last half a decade. It is time to accept that it needs to go and
there should be no runtime dependent switch for this. Valid PHP tags are
`https://t.me/psihius

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

[Robert Korulczyk]

> Many people have talked about the potential impacts of keeping short tags.
> I have yet to see anyone give an actual example where they have been
> negatively impacted by their existence. I've given you my personal story of
> how removing them will negatively impact my company. I welcome anyone that
> can provide an actual incident where the existence of short tags hurt them,
> or, the continued existence is likely to have a large negative impact on
> them in the future.

I was bitten by short open tags. Despite the "no short open tag" policy in our 
app, one occurrence of `http://www.php.net/unsub.php

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

[Arvids Godjuks]

чт, 8 авг. 2019 г. в 17:42, Chase Peeler :

>
>
> On Thu, Aug 8, 2019 at 11:18 AM Arvids Godjuks 
> wrote:
>
>> чт, 8 авг. 2019 г. в 16:42, Peter Kokot :
>>
>>> Hello,
>>> Thanks for sharing your stories about issues. Maybe we should start
>>> also thinking about the impact on the language attractiveness to pick
>>> it when starting a new web project since the core people can't come to
>>> conclusions how to make the language more consistent on the long run
>>> (PHP 9 etc)... With more and more ambiguities, inconsistencies,
>>> lockups, and dead ends behind the language there is probably also a
>>> bit of a factor to consider that it lowers this attractiveness.
>>> Meaning less people will think of adopting it (with all the things
>>> combined - short tags, that and that inconsistency not being removed
>>> from PHP due to major disastrous BC break there and there). So, the
>>> damage is also on the long run with more and more locks and dead ends
>>> not being able to be fixed and cleaned.
>>>
>>>
>>> --
>>> Peter Kokot
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>> Hello.
>>
>> Peter above put my thoughts perfectly.
>>
>> BC is great, but you need to pull the cord at some point. And the whole
>> short tag back and forth, with deprecation warning and stuff, has been
>> around for last half a decade. It is time to accept that it needs to go and
>> there should be no runtime dependent switch for this. Valid PHP tags are
>> `> I really liked how language picked up the cleanup pace in the last few
>> years and it needs it. I finally see genuine interest in people to actually
>> either come back or pick it up instead of JavaScript (NodeJS) and other
>> fancy new shiny stuff. And a lot of it is because of the cleanup efforts
>> and WTF?! removal, the language having the option to be stricter (I was not
>> a fan of strict mode when it was coming up - now I don't use anything else
>> - it is AWESOME).
>> If the old guard starts to push back as much as I have seen here, we are
>> going to lose momentum as a community and have people not willing to work
>> on PHP as much. I mean anyone who has been on this list for more than 10
>> years should remember how it was in 5.0-5.4 days - slow, painful and
>> somewhat unfriendly, until a few major contributors kind'a muddled though
>> and pushed a few major changes that allowed the momentum to build up and
>> somewhat break the stalemate (and it did help that HHVM reared it's head
>> and had stroked a few egos the wrong way). I guess the curve repeats
>> itself, but we should make an effort to curb it and not revert back to "BC,
>> BC, BC" holding everything up.
>>
>> Wait, how could positive progress have been made while short tags still
> existed?
>
>
>> Reality is, a lot of those "non-tech company" examples people give here
>> has nothing to do with language evolution. Yes, they are users, but we are
>> not responsible for the code they write, for the way they configure their
>> web servers and the way they can run a PHP4 server past 10 years and still
>> have no clue, because nobody cares or "it works, it makes money, no need to
>> invest". I would say that most of us on this list, if not everyone, are
>> smart enough to run/leave/not work for companies like that, so we are
>> somewhat shielded from that ignorance and just forget how bad it can be.
>>
>> Long story short - indecision is not an option. The previous RFC has
>> passed. Everyone involved, I hope, understands that yes, there will be
>> stuff going wrong for some users who are careless and/or ignorant and live
>> under a rock. Can we really do anything about that? I would say no unless
>> we freeze the language and do nothing. I mean I have exposed my PHP code
>> during server setup by just forgetting to do `systemctl reload nginx`,
>> hitting the URL and getting my `index.php` on the screen more times than I
>> care to confess to.
>>
> You're in the "all or nothing" logical fallacy. You are acting as if being
> against the removal of short tags is the same as being against any BC break
> at all. As we've said MANY times, BC breaks aren't the issue. THIS
> PARTICULAR BC BREAK IS THE ISSUE. It provides little to no positives to the
> users and does very little, if anything, to improve the language. At the
> same time it WILL lead to a very big barrier in terms of the ability to
> upgrade for a large number of users.
>

The RFC's both covered the fact that there is no good way to deprecate and
remove short tags cleanly. Whatever road you take - it is going to result
in issues for some users.
The crux here is not the tags themselves per-se, but the engine level
switch that changes the functionality of how the code is parsed. I mean if
push comes to shove and people really really really do not want to remove
`
>
>> Let's look into the future, use a reasonable amount of caution and/or
>> deprecation notice periods, but 

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

[Todd Ruth]

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

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

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

- Todd  (usually quiet here)

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

[Reinis Rozitis]

> -Original Message-
> From: Bishop Bettini [mailto:bis...@php.net]
>
> That's why I highlighted Robert Korulczyk's case study: only a particular 
> code path in a particular environment had the problem.
>
> The status quo enables deployments to fail insecurely.  "secret"; is a trap waiting to spring. I would rather require ten thousand
> people secure their environment by running a script, than risk a single person
> exposing their credentials for all to steal.
> 
> I challenge everyone who's voted no to consider this balance.


If the initial RFC would have been accepted as is (without the later proposed 
changes after the lengthy discussion) you would have sprung the same "trap" as 
in that particular case study -  code would be exposed.


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?

rr


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

[Benjamin Morel]

>
> I'm going to speak strictly as a userland PHP developer, for that is
> what I am.
> The idea of PHP being held hostage to eternal backwards compatibility
> fills me with absolute dread.
> (...)
> I can deal with short term pain for long term gain.
> What I would struggle to deal with is committing myself and my clients
> to a language and ecosystem where history was constantly allowed to
> trump pragmatism.
> I understand it's obviously a big challenge for the internals team and
> its contributors to create coexistent systems with versioning, but I
> would simply offer the following:
> If you're not going forward, you're falling behind, and sometimes going
> forward requires sacrifice.



This could not better match my feelings.
I've been a userland PHP developer for the last 15 years, have quite a
trail of code behind me, and would also love to deal with BC breaks.
No pain no gain.

Benjamin

On Fri, 9 Aug 2019 at 00:25, Mark Randall  wrote:

> On 08/08/2019 21:17, Zeev Suraski wrote:
> > [... and not in the Sith Lord kind of way.]
> > Thoughts?
>
> I'm going to speak strictly as a userland PHP developer, for that is
> what I am.
>
> The idea of PHP being held hostage to eternal backwards compatibility
> fills me with absolute dread.
>
> I've built most of my career on PHP, I find it a very powerful platform,
> but I find it lacking in some major areas. Some of those have reasonable
> workarounds (React, Swoole) and some of them do not (var level type
> enforcement, generics, universal annotations, first class functions and
> other symbols, union types, CoW classes etc).
>
> I hope that some day, these problems are going to be fixed, but in the
> process I understand they may pose backwards compatibility issues.
>
> If PHP as a language cannot push forwards out of a concern for perpetual
> backwards compatibility, then I have to start questioning if it makes
> sense for me, and those I work with, to continue using it in the long
> run, vs a platform which is willing to find a way to make those changes
> and push things forward. I'm thinking 5 - 10 years here.
>
> As a developer, having to spend time on fixing BC breaks is obviously a
> cost. However, not having things that would have saved me time, or
> allowed me to write better code if they were there, but weren't added
> because of BC, is also a cost.
>
> To my mind, I would be happy to see a situation where I can stick a
> declare in my file that says "Give me the good stuff and I will find a
> way to deal with the BC breaks".
>
> I can deal with short term pain for long term gain.
>
> What I would struggle to deal with is committing myself and my clients
> to a language and ecosystem where history was constantly allowed to
> trump pragmatism.
>
> I understand it's obviously a big challenge for the internals team and
> its contributors to create coexistent systems with versioning, but I
> would simply offer the following:
>
> If you're not going forward, you're falling behind, and sometimes going
> forward requires sacrifice.
>
> Mark Randall
>
>
> --
> 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

[Zeev Suraski]

On Fri, Aug 9, 2019 at 1:25 AM Mark Randall  wrote:

> On 08/08/2019 21:17, Zeev Suraski wrote:
> > [... and not in the Sith Lord kind of way.]
> > Thoughts?
>
> The idea of PHP being held hostage to eternal backwards compatibility
> fills me with absolute dread.
>
[snip]

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

I'd like to state three things, and ask another:
1.  The differences between the internals@ schools of thought aren't
limited to just downwards compatibility issues alone - these were
highlighted because of the recent short tags discussion, but that's just
one aspect out of several - which I mentioned in my message.
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.
3.  Putting your apparent personal bias against backwards compatibility
aside - if P++ goes in the directions you're hoping for - towards giving
you the goodies on your wish list, why would you care if PHP still existed
without these new changes/features?

Zeev

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

[Matthew Brown]

On Thu, 8 Aug 2019 at 19:08, Zeev Suraski  wrote:

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

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

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

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

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

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

[Brent]

Hi Zeev

Happy to see this proposal pop up, it's good to know that the "other side" is 
also open for long-term solutions. I think there needs to be a thorough 
analysis about the pros and cons of the two paths to take: a sister language 
vs. Nikita's proposal. To me, a userland developer, both solutions would have 
the same result in the end, so I trust internals to make a well-informed 
decision.

There's one thing I haven't seen mentioned yet though: what about the added 
workload for the core developers? You'll have to maintain two implementations 
of PHP, be it in the same runtime. Is this a load the core developers are able 
to carry? Aren't you afraid that development of the "old" version of PHP would 
quickly decline? If that were to happen, there's little difference in tagging a 
new major release with the breaking changes/cleanup we want.

Lastly, how do you envision interop between this two sister languages? Would a 
"normal" composer package be able to run in P++ ? You did mention P++ would 
share the same runtime, extensions, etc, but whether the runtime would be able 
to switch between the old and new version depending on the code wasn't clear to 
me.

Kind regards
Brent
On 8 Aug 2019, 23:59 +0200, Zeev Suraski , wrote:
> On Fri, Aug 9, 2019 at 12:22 AM Nikita Popov  wrote:
>
> > On Thu, Aug 8, 2019 at 11:02 PM Nikita Popov  wrote:
> >
> > > On Thu, Aug 8, 2019 at 10:17 PM Zeev Suraski  wrote:
> > >
> > > This is basically what I have been advocating for a while now already,
> > > somewhat hidden between all the other noise of the "namespace-scoped
> > > declares" thread. The model I would like to follow are Rust editions (
> > > https://doc.rust-lang.org/
> > > 
> > > edition-guide/editions/index.html
> > > ). In PHP
> > > right now, the way to do this technically would be based on a
> > > declare(edition=2020) in every file. I was hoping to make this a
> > > per-package declaration instead, but haven't found the perfect way to do
> > > this right now.
> > >
> > > I think that introducing this kind of concept for PHP is very, very
> > > important. We have a long list of issues that we cannot address due to
> > > backwards compatibility constraints and will never be able to address, on
> > > any timescale, without having the ability of opt-in migration.
> > >
> > > I do plan to create an RFC on this topic.
> > >
> >
> > After reading your mail again, I think what I have in mind is maybe quite
> > different from what you have in mind after all, even if the motivation and
> > purpose (language evolution without breaking legacy code) is the same.
> >
>
> I'd describe my motivations quite differently than that.
>
> First, I want to point out that my very first motivation was in fact a
> human one - hence the subject line. I think there's substantial value in
> finding a solution for the constant contention on internals, without
> neither camp giving up on their principals and beliefs.
>
> Secondly - the current language-base of PHP (7.x) won't be 'legacy'. I
> think there's going to be a lot of new code written in it, and I think a
> lot of people would prefer it over P++ - even in 5 or 10 years. Again,
> C/C++ is a very good analogy here. If one camp remains 'missionary' about
> forcing the other camp to assimilate as the long term goal - that's not at
> all what I'm talking about. This is also why an edition named 'PHP2020' is
> somewhat problematic - as it implies you're behind if you're not using it.
>
> My goal is to have two sister languages, with both PHP and P++ being equal
> among equals, and not PHP being the 'dead language walking' and P++ being
> the end goal of everything.
>
> In particular, you seem to have a pretty strong focus on introducing a
> > "new" language with a new name that just happens to interoperate with PHP.
> >
>
> Not quite - it doesn't just happen to interoperate with PHP. It shares the
> same runtime; It shares the same extensions; It shares many of the same
> tools; And most importantly - it's very similar in its syntax. Again,
> here too, the C/C++ analogy works really well. Would you say C++ is a new
> language that just happens to interoperate with C? It's obviously a lot
> more than that.
>
> I don't think that's a direction we should be going down.
> >
>
> Oh well :|
>
>
> > One of the larger issues with that is that it only works once: You have
> > one BC break point going between PHP and PHP++, but that's it. Unless you
> > want to rebrand your language every five years ;) What we need is something
> > that is sustainable in the long term.
> >
>
> I think that the one, big-scoped compatibility breakage is a feature, not a
> bug. At the risk of sounding like a broken record - the C/C++ analogy
> works well here too, this time specifically C++. You can evolve the new
> language - even substantially - but C++ always stayed C++ and C 

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

[Mark Randall]

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

[Bishop Bettini]

On Thu, Aug 8, 2019 at 3:35 PM Zeev Suraski  wrote:

> On Thu, Aug 8, 2019 at 9:10 PM Bishop Bettini  wrote:
>
>> On Tue, Aug 6, 2019 at 7:34 AM G. P. B.  wrote:
>>
>> > The voting for the "Deprecate short open tags, again" [1] RFC has begun.
>> > It is expected to last two (2) weeks until 2019-08-20.
>> >
>> > A counter argument to this RFC is available at
>> > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags
>> >
>
> If anyone needs to justify the effort, let them say "> hole".
>>
>
> It's a security hole in the exact same level that httpd.conf is a security
> hole.  Yes, misconfiguring your Web server can have severe consequences.
> Thankfully, it's not nearly that big of a Thing for us to be concerned
> about.
>

No, not even close to the same level.

If my web server's misconfigured, (ALL) of my code's exposed. It's trivial
to write a test to prove that my web server is properly serving PHP files.

But if PHP's misconfigured, (all OR some OR none) of my code's exposed. The
only way to decide is to literally check everything. That's why I
highlighted Robert Korulczyk's case study: only a particular code path in a
particular environment had the problem.

The status quo enables deployments to fail insecurely. 

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

[Rowan Collins]

On Wed, 7 Aug 2019 at 20:45, Sergey Panteleev  wrote:

> Hi there!
>
> Perhaps I missed and someone already suggested,
> but didn't consider a compromise option:
> just change the default value short_open_tag=false,
> and DON'T removes the option from php.ini?
>
> If someone uses short tags - ok, they will change
> the default value to true and everything will be as before,
> who won't change it - will enjoy the full syntax
>


Defaulting it to "off" would risk leaking people's code if they didn't set
it, but I suggested earlier that it could default to a new "error" mode
(which could also be explicitly set):
https://externals.io/message/106384#106408

Regards,
-- 
Rowan Collins
[IMSoP]

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

[Reinis Rozitis]

> -Original Message-
> From: Brent [mailto:bre...@stitcher.io]
>
>
> It feels like much of the counter arguments are based on guesses without any
> real data to point to.

It goes both ways - the argument for removal states "This means that their use 
is not possible in portable code, because the code author does not necessarily 
have the necessary control over the configuration".

What is the number/statistics of developers which have written a portable (in 
their mind) code (which means NOT using short tags) just to find out that the 
code/application doesn't work because those are disabled?

Is there real data for that?

rr 


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

[Chase Peeler]

On Thu, Aug 8, 2019 at 9:35 AM Zeev Suraski  wrote:

> On Thu, Aug 8, 2019 at 3:17 PM Brent  wrote:
>
> > I asked similar questions on Twitter, where Zeev replied the following:
> > https://mobile.twitter.com/zeevs/status/115865658046464
>
>
> I want to add a bit of color to this tweet:
> - Estimated # of developers using PHP is at around 10M.  This is based on
> some extrapolation from an EDS report from ~8 years ago that estimated that
> number at >6M, and growth rates we've seen beforehand.
> - Anecdotally, I've seen it used many times in non-distributable code over
> the years - a lot more frequently than once per 100 users.
> - Even if just 1% of the userbase uses short tags, that's ~100K.  We can
> call this one a guess, but I'd say it's an educated guess that there's well
> above 1% of the PHP userbase that uses short tags.
>
> It feels like much of the counter arguments are based on guesses without
> > any real data to point to.
>
>
> I wouldn't say they're guesses, but extrapolations - for instance, the fact
> I'm aware of many PHP frameworks and apps, and am not aware of any single
> one that allows short tags - makes me feel fairly comfortable to make the
> statement that "virtually all frameworks and apps designed for public
> consumption disallow short tags".  I can't preclude the possibility that
> the fact that all of the apps and frameworks I'm aware of don't allow short
> tags is a remarkable coincidence - or that there are countless ones I'm not
> aware of that do allow short tags - but I think that my theory is a lot
> more plausible.
>
> I work on an internal application. Even though portability is not a
concern for anything we write, we haven't used short tags since it was
rumored they were going to be removed in PHP 6 many years ago. That being
said, this application has been in development since 2003. There is a large
amount of legacy code written before I even started here, not to mention
plenty of horrible code written after I did start in 2005 (this was my
first job). As I mentioned in an email on this thread yesterday, most of
our legacy code is "just leave it alone, it works" code. We are in the
process of rewriting things, but, that takes time. We try and mess with the
legacy code as little as possible. Something as simple as auto formatting
with PhpStorm has broken things in the past - so I don't trust an automated
tool to fix the short tags for me. Even if I'm the only person that has
participated in this thread that has to maintain a codebase that consists
of non-portable code with a large amount of short tags, that's still at
least 1% of those that have participated in this thread, or one of its
predecessors.

Another thing to keep in mind is that most of the people writing and/or
maintaining "non-portable" code probably don't work for a company in the
software development industry. When I want to upgrade PHP, I have to
convince our leadership of the value of me spending a couple of weeks
fixing BC breaks. I have to show why that is more valuable than spending
time on the development of new functionality. The more time required to do
an upgrade, the more likely it will get punted to a future date.

I'm not against BC breaks in general - they are a necessary evil. However,
it's important that the negative impact of that break is far outweighed by
the positive value it brings. I'll leave it up to each of you to determine
how positive of an impact removing short tags would bring. I can promise
you, though, that the negative impact would be VERY large. Just because you
don't personally have to maintain any code that uses short tags doesn't
mean that there aren't other developers out there that do. Every BC break
is going to lead to a subset of users that will decide to not upgrade as a
result. It will also lead to a subset of users that will decide to use a
different technology (node, .NET, python, etc.) going forward. Many BC
breaks are worth that risk. Is this one of them?

Many people have talked about the potential impacts of keeping short tags.
I have yet to see anyone give an actual example where they have been
negatively impacted by their existence. I've given you my personal story of
how removing them will negatively impact my company. I welcome anyone that
can provide an actual incident where the existence of short tags hurt them,
or, the continued existence is likely to have a large negative impact on
them in the future.


> Zeev
>


-- 
Chase Peeler
chasepee...@gmail.com

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

[Rowan Collins]

On 8 August 2019 13:16:56 BST, Brent  wrote:
>I asked similar questions on Twitter, where Zeev replied the
>following:
>
>> With an estimated number of PHP developers
>> at 10M, 1% is 100K. Whether I know this for
>> sure is not at all the point - it's never how we
>> take decisions. The question is whether it's
>> reasonable or not. And my guess is that a lot
>> more than 1% uses short tags.
>
>It feels like much of the counter arguments are based on guesses
>without any real data to point to.


You can take that both ways though: the argument that short tags should be 
removed is based on the same guesses. 

I understand Zeev's frustration in being asked to provide the proof when his 
position is that we shouldn't be spending any time on the issue at all. It 
should be up to those who think a change is necessary to demonstrate both the 
harm of the status quo (e.g. real-world cases of code exposure), and that it 
outweighs the cost of change (e.g. how many users will need to change working 
code).

It would be different if we were choosing between two versions of some feature, 
but no-change should always have a starting advantage over change, which is why 
we require a super-majority in primary RFC votes.

Regards,
-- 
Rowan Collins
[IMSoP]

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

[Brent]

I asked similar questions on Twitter, where Zeev replied the following: 
https://mobile.twitter.com/zeevs/status/115865658046464

It feels like much of the counter arguments are based on guesses without any 
real data to point to. On the other hand it's unfair to dismiss the counter 
arguments altogether because of this, as there's no way to gather accurate data 
about the usage of short open tags, let alone know how many developers using 
them actually plan on ever upgrading to 7.4…

Kind regards
Brent
On 8 Aug 2019, 12:27 +0200, Côme Chilliet , wrote:
> Le mercredi 7 août 2019, 15:57:02 CEST Chase Peeler a écrit :
> > Pretty much everyone (if not actually
> > everyone) that is against this RFC has stated that they don't actually use
> > short tags, and do not advocate that anyone else use them either.
>
> This is what bugs me, the counter argument page from Zeev states «I never use 
> short tags in any PHP code that I write, and as far as I recall - I never 
> have. »,
> and at the same time «put hundreds of thousands of people through additional 
> pain when upgrading.»
>
> Is there any data that support the theory that hundreds of thousands of 
> people use short tags?
>
> Did anyone in this discussion stated that he was using them?
>
> --
> 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

[Zeev Suraski]

On Thu, Aug 8, 2019 at 3:17 PM Brent  wrote:

> I asked similar questions on Twitter, where Zeev replied the following:
> https://mobile.twitter.com/zeevs/status/115865658046464


I want to add a bit of color to this tweet:
- Estimated # of developers using PHP is at around 10M.  This is based on
some extrapolation from an EDS report from ~8 years ago that estimated that
number at >6M, and growth rates we've seen beforehand.
- Anecdotally, I've seen it used many times in non-distributable code over
the years - a lot more frequently than once per 100 users.
- Even if just 1% of the userbase uses short tags, that's ~100K.  We can
call this one a guess, but I'd say it's an educated guess that there's well
above 1% of the PHP userbase that uses short tags.

It feels like much of the counter arguments are based on guesses without
> any real data to point to.


I wouldn't say they're guesses, but extrapolations - for instance, the fact
I'm aware of many PHP frameworks and apps, and am not aware of any single
one that allows short tags - makes me feel fairly comfortable to make the
statement that "virtually all frameworks and apps designed for public
consumption disallow short tags".  I can't preclude the possibility that
the fact that all of the apps and frameworks I'm aware of don't allow short
tags is a remarkable coincidence - or that there are countless ones I'm not
aware of that do allow short tags - but I think that my theory is a lot
more plausible.

Zeev

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

[Côme Chilliet]

Le mercredi 7 août 2019, 15:57:02 CEST Chase Peeler a écrit :
> Pretty much everyone (if not actually
> everyone) that is against this RFC has stated that they don't actually use
> short tags, and do not advocate that anyone else use them either.

This is what bugs me, the counter argument page from Zeev states «I never use 
short tags in any PHP code that I write, and as far as I recall - I never have. 
»,
 and at the same time «put hundreds of thousands of people through additional 
pain when upgrading.»

Is there any data that support the theory that hundreds of thousands of people 
use short tags?

Did anyone in this discussion stated that he was using them?

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

> -Original Message-
> From: Côme Chilliet [mailto:c...@opensides.be]
>
> This is what bugs me, the counter argument page from Zeev states «I never
> use short tags in any PHP code that I write, and as far as I recall - I never
> have. »,  and at the same time «put hundreds of thousands of people
> through additional pain when upgrading.»

Why does/should it bug you? The statements aren't contradictory. 
There are (must be) a lot of features which a particular language developer 
might not use (or even find ridiculous) himself personally but those still have 
been implemented historically or for future use for other users/clients etc.


> Did anyone in this discussion stated that he was using them?

Yes.

rr


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