[PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

  105201
April 10, 2019 10:43 george.banyard@gmail.com ("G. P. B.")
Hello Internals,

As there have been no further comments the voting for my RFC [1] to
deprecate PHP's
short open tags has started and will run for two (2) weeks.

Best regards

George P. Banyard

[1] https://wiki.php.net/rfc/deprecate_php_short_tags
  105226
April 10, 2019 21:49 netmo.php@gmail.com (Wes)
Finally!!! everybody will be able to parse my xml files with embedded
php!!!!1!1 if I ever wrote one!!!

Sorry for the sarcasm, please don't consider this as a personal attack. The
whole community (not just you) considers short open tags poison because not
XML-compatible... while they use stuff like twig, which is also not
XML-compatible.

This is just beyond my understanding.

But sure, let's keep vilifying this kind stuff and pretend they are the
root cause of PHP's bad rep.

Sorry again for the negativity.
  105227
April 10, 2019 22:54 mo.mu.wss@gmail.com ("M. W. Moe")
deprecate short closing tag
php@gmail.com> wrote:
> > Finally!!! everybody will be able to parse my xml files with embedded > php!!!!1!1 if I ever wrote one!!! > > Sorry for the sarcasm, please don't consider this as a personal attack. The > whole community (not just you) considers short open tags poison because not > XML-compatible... while they use stuff like twig, which is also not > XML-compatible. > > This is just beyond my understanding. > > But sure, let's keep vilifying this kind stuff and pretend they are the > root cause of PHP's bad rep. > > Sorry again for the negativity.
  105232
April 11, 2019 08:12 robert@korulczyk.pl (Robert Korulczyk)
> Sorry for the sarcasm, please don't consider this as a personal attack. The > whole community (not just you) considers short open tags poison because not > XML-compatible...
This is rather removing another trap from the language. As long as short open tags exist and depend on INI directive, there will be bugs and source code leaks after moving application to a different environment. Using > Finally!!! everybody will be able to parse my xml files with embedded > php!!!!1!1 if I ever wrote one!!! > > Sorry for the sarcasm, please don't consider this as a personal attack. The > whole community (not just you) considers short open tags poison because not > XML-compatible... while they use stuff like twig, which is also not > XML-compatible. > > This is just beyond my understanding. > > But sure, let's keep vilifying this kind stuff and pretend they are the > root cause of PHP's bad rep. > > Sorry again for the negativity. >
  105244
April 11, 2019 15:36 thruska@cubiclesoft.com (Thomas Hruska)
On 4/11/2019 1:12 AM, Robert Korulczyk wrote:
>> Sorry for the sarcasm, please don't consider this as a personal attack. The >> whole community (not just you) considers short open tags poison because not >> XML-compatible... > > This is rather removing another trap from the language. As long as short open tags exist and depend on INI directive, there will be bugs and source > code leaks after moving application to a different environment. Using external tool to enforce this.
I wouldn't say it is the ONLY safe way. Turning it on permanently would also solve the problem and there's also allowing 'http://cubiclesoft.com/ And once you find my software useful: http://cubiclesoft.com/donate/
  105248
April 11, 2019 16:51 robert@korulczyk.pl (Robert Korulczyk)
> Turning it on permanently would also solve the problem
Well, yes, although it creates "another way of doing the same thing". So far PHP was on a way to remove redundant tags. Permanently enabling of short open tags looks like a move in the opposite direction. Personally, I'm surprised by the controversy around this change. So far it was an obvious anti-pattern for me, and never seen anybody who was aware of the consequences of using > On 4/11/2019 1:12 AM, Robert Korulczyk wrote: >>> Sorry for the sarcasm, please don't consider this as a personal attack. The >>> whole community (not just you) considers short open tags poison because not >>> XML-compatible... >> >> This is rather removing another trap from the language. As long as short open tags exist and depend on INI directive, there will be bugs and source >> code leaks after moving application to a different environment. Using > external tool to enforce this. > > I wouldn't say it is the ONLY safe way.  Turning it on permanently would also solve the problem and there's also allowing ' as a permanent always-on option.  (Native XML compatibility is a complaint, not a requirement of a language.  XML is also basically dead in my corner > of the PHP universe, only ever cropping up on very rare and very confused occasions.) > > It's going to be interesting to see how many people who rely on and *prefer* using short open tags in internal systems come out of the woodwork when > PHP 7.4 and 8 drops.  Maybe I'm the only one who likes saving a few characters here and there and thinks code is more readable without the verbose tag. > > The vote is on the knife's edge of passing/failing at the moment and could go a couple of unusual directions as already noted elsewhere. This is > probably the most interesting RFC *vote* to happen in a long while. >
  105252
April 11, 2019 19:48 r@roze.lv ("Reinis Rozitis")
> From: Robert Korulczyk [mailto:robert@korulczyk.pl] > > Personally, I'm surprised by the controversy around this change. So far it was an > obvious anti-pattern for me, and never seen anybody who was aware of the > consequences of using It's not really a problem for programmers/coders writing new code rather for server providers/administrators (maybe also a reason why such issues are not (or rarely) voiced in a language development internal list) hosting legacy applications where no one wants or there is nobody to fix anything (even more with an automatic third party tool) and then there won't even be a switch (ini option) anymore for backwards compability. So you are (will be) forced to stay on EOL php version or implement a patch for reverting particular thing in your distro/custom package. p.s. somewhat similar is the situation with 'mysql' extension which by default prints a lot of deprecated warnings even being in pecl and basically the same wrapper around mysqlnd as mysqli/pdo, but at least there is still an option if your code really requires mysql_* (and many thanks to the people like Dmitry, Matteo who still make it compatible with the actual php versions). rr
  105368
April 24, 2019 11:28 george.banyard@gmail.com ("G. P. B.")
Hello Internal,

The two weeks of voting have now ended.
The results are 38 for and 18 against (total 56) for the primary vote to
deprecate PHP's short open tag in PHP 7.4.
This passes in favor with 68%.

The results are 42 for and 15 against (total 57) for the secondary vote to
remove PHP's short open tag in PHP 8.
This passes in favor with 74%.

Thanks for everyone who voted on this issue.

Best regards

George P. Banyard

>
  105371
April 24, 2019 13:41 vsuraski@gmail.com
FWIW,

I think it's a bad decision, made against the thoughts of clear majority of core developers - and for hardly a good reason.  I believe it illustrates very well why we need to properly define our voting eligibility rules, and I hope someone would be up to the challenge of tackling it (I decided not to pursue it further after the 'abolish' RFC(s)).

A 68% majority which barely clears the 2/3 requirements for something as fundamental as that - with so many core devs against it - we'll deserve all the criticism that will be coming our way in 7.4/8.0 from end users wondering why we needlessly broke their apps and made migration a bit more of a headache.

My 2c.

Zeev


-----Original Message-----
From: G. P. B. banyard@gmail.com> 
Sent: Wednesday, April 24, 2019 2:29 PM
To: PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

Hello Internal,

The two weeks of voting have now ended.
The results are 38 for and 18 against (total 56) for the primary vote to deprecate PHP's short open tag in PHP 7.4.
This passes in favor with 68%.

The results are 42 for and 15 against (total 57) for the secondary vote to remove PHP's short open tag in PHP 8.
This passes in favor with 74%.

Thanks for everyone who voted on this issue.

Best regards

George P. Banyard

>
  105372
April 24, 2019 14:00 lester@lsces.co.uk (Lester Caine)
On 24/04/2019 14:41, vsuraski@gmail.com wrote:
> A 68% majority which barely clears the 2/3 requirements for something as fundamental as that - with so many core devs against it - we'll deserve all the criticism that will be coming our way in 7.4/8.0 from end users wondering why we needlessly broke their apps and made migration a bit more of a headache.
This is yet another negative move in my forward planning and just another cross against even bothering with PHP8 ... and PHP7.4 is only going to complain about things so while I've not even started testing on PHP7.3, that is likely to be the last version of PHP I will be using ... once all the warnings are dealt with on PHP7.2 ... I don't think even the carrot of 'JIT' this time trumps being beaten around the head with more and more BC changes we will to have to manage and adding 'php' to every https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
  105374
April 24, 2019 14:35 chasepeeler@gmail.com (Chase Peeler)
On Wed, Apr 24, 2019 at 10:00 AM Lester Caine <lester@lsces.co.uk> wrote:

> On 24/04/2019 14:41, vsuraski@gmail.com wrote: > > A 68% majority which barely clears the 2/3 requirements for something as > fundamental as that - with so many core devs against it - we'll deserve all > the criticism that will be coming our way in 7.4/8.0 from end users > wondering why we needlessly broke their apps and made migration a bit more > of a headache. > > This is yet another negative move in my forward planning and just > another cross against even bothering with PHP8 ... and PHP7.4 is only > going to complain about things so while I've not even started testing on > PHP7.3, that is likely to be the last version of PHP I will be using ... > once all the warnings are dealt with on PHP7.2 ... I don't think even > the carrot of 'JIT' this time trumps being beaten around the head with > more and more BC changes we will to have to manage and adding 'php' to > every all the other attempts at removing descriptive text elsewhere. > > Total files scanned: 20,767 Total lines scanned: 4,013,170
Total short open tag references: 6,787 Total files w/ short open tag references: 1,665 If I get started now, maybe I can have everything fixed by the time 8.1 is released.
> -- > Lester Caine - G8HFL > ----------------------------- > Contact - https://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - https://lsces.co.uk > EnquirySolve - https://enquirysolve.com/ > Model Engineers Digital Workshop - https://medw.co.uk > Rainbow Digital Media - https://rainbowdigitalmedia.co.uk > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- Chase Peeler chasepeeler@gmail.com
  105378
April 24, 2019 15:02 php-lists@koalephant.com (Stephen Reay)
> On 24 Apr 2019, at 21:35, Chase Peeler <chasepeeler@gmail.com> wrote: > > If I get started now, maybe I can have everything fixed by the time 8.1 is > released.
Two characters less than this sentence of yours is a 1-liner find/sed script to replace all `
  105380
April 24, 2019 15:16 chasepeeler@gmail.com (Chase Peeler)
On Wed, Apr 24, 2019 at 11:02 AM Stephen Reay <php-lists@koalephant.com>
wrote:

> > > On 24 Apr 2019, at 21:35, Chase Peeler <chasepeeler@gmail.com> wrote: > > > > If I get started now, maybe I can have everything fixed by the time 8.1 > is > > released. > > > Two characters less than this sentence of yours is a 1-liner find/sed > script to replace all ` Would you really feel confident doing a blind find/replace on 6,000+ instances? what about chasepeeler@gmail.com
  105381
April 24, 2019 15:27 php-lists@koalephant.com (Stephen Reay)
> On 24 Apr 2019, at 22:16, Chase Peeler <chasepeeler@gmail.com> wrote: > > > > On Wed, Apr 24, 2019 at 11:02 AM Stephen Reay <php-lists@koalephant.com <mailto:php-lists@koalephant.com>> wrote: > > > On 24 Apr 2019, at 21:35, Chase Peeler <chasepeeler@gmail.com <mailto:chasepeeler@gmail.com>> wrote: > > > > If I get started now, maybe I can have everything fixed by the time 8.1 is > > released. > > > Two characters less than this sentence of yours is a 1-liner find/sed script to replace all ` Would you really feel confident doing a blind find/replace on 6,000+ instances?
It’s hardly “blind”. This is what version control is for. You make a change, and then either view the diff locally, and/or commit/push it, and ask others to help review the diff. I literally just ran the script referenced above on a client project, eyeballed the diff, and committed the changes it made to a branch. Once I’m not in the middle of anything I’ll review it again and then merge it.
> > what about So change the pattern to replace `> > What if I utilize a 3rd party library that, while no longer support, works fine, but is now broken for no other reason than the fact that
You do the same thing as if the library had a security issue or some other bug. If it’s unsupported, you have to support it, or you have to find a replacement. It’s not like you’re dealing with a compiled module that you can’t edit. Run the same fix for short tags on the library.
> I don't trust mass find/replace tools like php-cs-fixer. Some of our legacy code is really ugly. Auto-formatting with PhpStorm will break it. I don't mind using an interactive tool, but that means I have to sit there and hit Y or N for 6,787 instances. Some of them will probably require me to actually open the file up and check out the surrounding context as well. And, what happens if I miss one? I run the risk of code leak.
If auto formatting ‘breaks’ your code, you have a bigger problem than short tags.
> > I think it's great that many of you have code bases that are in pretty good shape and this change isn't going to have much of an impact on you. That's not my case, though. It's not the case for a LOT of people. I'm not against BC breaks - even major ones - if they are justified. I have yet to see any good justifications for such a massive BC break. > > The fact is that this change WILL prevent a lot of people from being able to upgrade to 8.0 in a timely manner. Anyone that has to justify spending time to prepare for an upgrade to people that don't understand the benefits of the upgrade will have an ever harder time trying to justify the extra time necessary. I also think you are going to find a good number of people that will upgrade (or use PHP for the first time) unaware of the change. They'll attempt to load older code that has short tags in it. It won't work. They'll say "screw it" and use python or node. > -- > Chase Peeler > chasepeeler@gmail.com <mailto:chasepeeler@gmail.com>
  105382
April 24, 2019 15:50 chasepeeler@gmail.com (Chase Peeler)
On Wed, Apr 24, 2019 at 11:27 AM Stephen Reay <php-lists@koalephant.com>
wrote:

> > > On 24 Apr 2019, at 22:16, Chase Peeler <chasepeeler@gmail.com> wrote: > > > > > > > > On Wed, Apr 24, 2019 at 11:02 AM Stephen Reay <php-lists@koalephant.com > <mailto:php-lists@koalephant.com>> wrote: > > > > > On 24 Apr 2019, at 21:35, Chase Peeler <chasepeeler@gmail.com chasepeeler@gmail.com>> wrote: > > > > > > If I get started now, maybe I can have everything fixed by the time > 8.1 is > > > released. > > > > > > Two characters less than this sentence of yours is a 1-liner find/sed > script to replace all ` > Would you really feel confident doing a blind find/replace on 6,000+ > instances? > > It’s hardly “blind”. This is what version control is for. You make a > change, and then either view the diff locally, and/or commit/push it, and > ask others to help review the diff. > > I literally just ran the script referenced above on a client project, > eyeballed the diff, and committed the changes it made to a branch. Once I’m > not in the middle of anything I’ll review it again and then merge it. > > How big of a project? How many changes? You really think 6,787 changes among 1,656 files can just be eyeballed?
> > > > what about in my code, though. > > So change the pattern to replace ` equals sign. > > though, if something is using eval, god forbid. '> > > > What if I utilize a 3rd party library that, while no longer support, > works fine, but is now broken for no other reason than the fact that no longer supported? Whether I should be using that library or not is > irrelevant. The fact is, I am, and the fact that I won't be able to use it > in 8.0 is a barrier to me upgrading. > > > > You do the same thing as if the library had a security issue or some other > bug. If it’s unsupported, you have to support it, or you have to find a > replacement. It’s not like you’re dealing with a compiled module that you > can’t edit. Run the same fix for short tags on the library. > > All valid options. Doesn't change the fact that it's more code to update meaning more time required to prepare for the upgrade.
> > I don't trust mass find/replace tools like php-cs-fixer. Some of our > legacy code is really ugly. Auto-formatting with PhpStorm will break it. I > don't mind using an interactive tool, but that means I have to sit there > and hit Y or N for 6,787 instances. Some of them will probably require me > to actually open the file up and check out the surrounding context as well. > And, what happens if I miss one? I run the risk of code leak. > > If auto formatting ‘breaks’ your code, you have a bigger problem than > short tags. > > I never said that our code was good. Most of our legacy code isn't ever touched. It's a mess of 10k+ line spaghetti files. It works, and until we
are able to replace it, we just leave it alone. Now we are forced to go in there and mess with it for something that doesn't even pertain to the functionality of our application. Also, you didn't address the issue of missed instances. There is no way to be 100% sure any automated or manual process of replacing the tags will get everything. One of the justifications for this RFC was the possibility of code leak if code with short tags is loaded in an environment that has short tags disabled. We've decided to fix that by making sure that any code with short tags will DEFINITELY leak code. That makes a lot of sense. Eyeballing a diff isn't going to help you find missed instances either.
> > > > I think it's great that many of you have code bases that are in pretty > good shape and this change isn't going to have much of an impact on you. > That's not my case, though. It's not the case for a LOT of people. I'm not > against BC breaks - even major ones - if they are justified. I have yet to > see any good justifications for such a massive BC break. > > > > The fact is that this change WILL prevent a lot of people from being > able to upgrade to 8.0 in a timely manner. Anyone that has to justify > spending time to prepare for an upgrade to people that don't understand the > benefits of the upgrade will have an ever harder time trying to justify the > extra time necessary. I also think you are going to find a good number of > people that will upgrade (or use PHP for the first time) unaware of the > change. They'll attempt to load older code that has short tags in it. It > won't work. They'll say "screw it" and use python or node. > > -- > > Chase Peeler > > chasepeeler@gmail.com <mailto:chasepeeler@gmail.com> > > It's not that I'm against the idea of abolishing short tags. It's that I don't feel the problems abolishing them will cause are justified by the
reasons given for abolishing them. No matter how easy you think it is to deal with this, it won't change the fact that it's going to be a barrier to upgrading for a lot of people. It's going to have a negative impact on 8.0 adoption. It's going to lead to a larger number of people running PHP versions that have reached EOL. In the end, it's going to hurt the market share and reputation of PHP. -- Chase Peeler chasepeeler@gmail.com
  105384
April 24, 2019 16:06 markyr@gmail.com (Mark Randall)
On 24/04/2019 15:35, Chase Peeler wrote:
>> Total files scanned: 20,767 > Total lines scanned: 4,013,170 > Total short open tag references: 6,787 > Total files w/ short open tag references: 1,665
1. Open project in PHPStorm (or equivalent). 2. Run inspections. 3. Click convert short open tags. Personally I prefer the shorter look of "" when writing templates, but not enough to be up in arms about its removal. If anything I'm more concerned about potential code + data leaks. Something which was previously perfectly legitimate code, no longer being considered code, could be quite the problematic situation... especially if that code happened to be protective logic such as "if" statements. User secret: I would have preferred that the parser encountering
  105375
April 24, 2019 14:36 php-lists@koalephant.com (Stephen Reay)
> On 24 Apr 2019, at 21:00, Lester Caine <lester@lsces.co.uk> wrote: > > On 24/04/2019 14:41, vsuraski@gmail.com wrote: >> A 68% majority which barely clears the 2/3 requirements for something as fundamental as that - with so many core devs against it - we'll deserve all the criticism that will be coming our way in 7.4/8.0 from end users wondering why we needlessly broke their apps and made migration a bit more of a headache. > > This is yet another negative move in my forward planning and just another cross against even bothering with PHP8 ... and PHP7.4 is only going to complain about things so while I've not even started testing on PHP7.3, that is likely to be the last version of PHP I will be using ... once all the warnings are dealt with on PHP7.2 ... I don't think even the carrot of 'JIT' this time trumps being beaten around the head with more and more BC changes we will to have to manage and adding 'php' to every > -- > Lester Caine - G8HFL > ----------------------------- > Contact - https://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - https://lsces.co.uk > EnquirySolve - https://enquirysolve.com/ > Model Engineers Digital Workshop - https://medw.co.uk > Rainbow Digital Media - https://rainbowdigitalmedia.co.uk > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
Of all the things to ‘refuse to upgrade’ over this seems pretty silly. There are multiple tools that will automatically fix this across an entire codebase in seconds. Heck, a sed 1 liner would do it if you want to DIY it.
  105376
April 24, 2019 14:56 lester@lsces.co.uk (Lester Caine)
On 24/04/2019 15:36, Stephen Reay wrote:
> Of all the things to ‘refuse to upgrade’ over this seems pretty silly. There are multiple tools that will automatically fix this across an entire codebase in seconds. Heck, a sed 1 liner would do it if you want to DIY it.
Another nail rather a reason it it's own right, and I've looked at these 'automatic tools' and until there is one that does not enforce their own views of code style they are just another nail ... it's bad enough when tidy TABBED code gets messed up by someone replacing them all with multiple spaces because that is 'the proper way to do it' ... this is long established coding style issue not simply automatic edits to code that IS working perfectly already. It does not 'fixing' simply because some people don't like it ... -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
  105379
April 24, 2019 15:07 php-lists@koalephant.com (Stephen Reay)
> On 24 Apr 2019, at 21:56, Lester Caine <lester@lsces.co.uk> wrote: > > I've looked at these 'automatic tools' and until there is one that does not enforce their own views of code style they are just another nail
While the pre-build rules may not be what you want - something like PHP_CodeSniffer will let you just run a single ‘sniff’ type by passing it’s name. Or use an IDE that has built-in support for inspections/fixing like this, or, as I said, run sed over your project files. Replacing ‘
  105392
April 24, 2019 16:39 lester@lsces.co.uk (Lester Caine)
On 24/04/2019 16:07, Stephen Reay wrote:
> Or use an IDE that has built-in support for inspections/fixing like this, or, as I said, run sed over your project files. Replacing ‘ But why should I have to bother at all? As others have indicated in templates is tidier and HAVING to add thousands of 'php' to the templates serves no purpose other than bowing to other peoples coding styles! There are other easier ways of shooting myself in the foot especially since https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
  105393
April 24, 2019 17:01 peterkokot@gmail.com (Peter Kokot)
Hello,

just a friendly reminder that by the time one writes an email here
these tags can be already replaced with the usual ones. Here is an
example of running php-cs-fixer to replace the legacy tags to the full
opening tags:

    php-cs-fixer fix --rules=full_opening_tag --diff --dry-run
/path/to/php/files/with/short/tags


And then actually replacing them (without dry run):

    php-cs-fixer fix --rules=full_opening_tag --diff
/path/to/php/files/with/short/tags

-- 
Peter Kokot
  105394
April 24, 2019 17:10 cschneid@cschneid.com (Christian Schneider)
Am 24.04.2019 um 19:01 schrieb Peter Kokot <peterkokot@gmail.com>:
> just a friendly reminder that by the time one writes an email here > these tags can be already replaced with the usual ones.
A friendly reminder that some people are hosting customer code which they do not want to touch but will get support requests once the code breaks. - Chris
  105395
April 24, 2019 17:13 chasepeeler@gmail.com (Chase Peeler)
On Wed, Apr 24, 2019 at 1:10 PM Christian Schneider <cschneid@cschneid.com>
wrote:

> Am 24.04.2019 um 19:01 schrieb Peter Kokot <peterkokot@gmail.com>: > > just a friendly reminder that by the time one writes an email here > > these tags can be already replaced with the usual ones. > > A friendly reminder that some people are hosting customer code which they > do not want to touch but will get support requests once the code breaks. > > Whether we are fixing it proactively or reactively, the bottom line is that we're making modifications to code that don't fix a bug or provide an
enhancement. It involves risk with no reward.
> - Chris > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- Chase Peeler chasepeeler@gmail.com
  105396
April 24, 2019 17:13 ocramius@gmail.com (Marco Pivetta)
On Wed, 24 Apr 2019, 19:10 Christian Schneider, <cschneid@cschneid.com>
wrote:

> Am 24.04.2019 um 19:01 schrieb Peter Kokot <peterkokot@gmail.com>: > > just a friendly reminder that by the time one writes an email here > > these tags can be already replaced with the usual ones. > > A friendly reminder that some people are hosting customer code which they > do not want to touch but will get support requests once the code breaks. > > - Chris >
That's normal? Everyone has projects to maintain, and breaking changes are common: they're gonna call you for one anyway: if you don't like that, then you are in the wrong line of business.
>
  105398
April 24, 2019 17:25 cschneid@cschneid.com (Christian Schneider)
Am 24.04.2019 um 19:13 schrieb Marco Pivetta <ocramius@gmail.com>:
> On Wed, 24 Apr 2019, 19:10 Christian Schneider, <cschneid@cschneid.com> wrote: > Am 24.04.2019 um 19:01 schrieb Peter Kokot <peterkokot@gmail.com>: > > just a friendly reminder that by the time one writes an email here > > these tags can be already replaced with the usual ones. > > A friendly reminder that some people are hosting customer code which they do not want to touch but will get support requests once the code breaks. > > - Chris > > That's normal? Everyone has projects to maintain, and breaking changes are common: they're gonna call you for one anyway: if you don't like that, then you are in the wrong line of business.
See Chase Peeler's point: A breaking change should have a reward big enough to justify it. And that's what where we (including Zeev Suraski and other core developers) disagree. - Chris
  105399
April 24, 2019 17:27 ocramius@gmail.com (Marco Pivetta)
On Wed, 24 Apr 2019, 19:25 Christian Schneider, <cschneid@cschneid.com>
wrote:

> Am 24.04.2019 um 19:13 schrieb Marco Pivetta <ocramius@gmail.com>: > > On Wed, 24 Apr 2019, 19:10 Christian Schneider, <cschneid@cschneid.com> > wrote: > > Am 24.04.2019 um 19:01 schrieb Peter Kokot <peterkokot@gmail.com>: > > > just a friendly reminder that by the time one writes an email here > > > these tags can be already replaced with the usual ones. > > > > A friendly reminder that some people are hosting customer code which > they do not want to touch but will get support requests once the code > breaks. > > > > - Chris > > > > That's normal? Everyone has projects to maintain, and breaking changes > are common: they're gonna call you for one anyway: if you don't like that, > then you are in the wrong line of business. > > See Chase Peeler's point: A breaking change should have a reward big > enough to justify it. > And that's what where we (including Zeev Suraski and other core > developers) disagree. > > - Chris >
Run a fixer: they are out there, and they are extremely stable too. Also a good chance to finally take a look at code that has been rotting in a hard drive for too much time.
  105400
April 24, 2019 17:43 chasepeeler@gmail.com (Chase Peeler)
On Wed, Apr 24, 2019 at 1:27 PM Marco Pivetta <ocramius@gmail.com> wrote:

> On Wed, 24 Apr 2019, 19:25 Christian Schneider, <cschneid@cschneid.com> > wrote: > > > Am 24.04.2019 um 19:13 schrieb Marco Pivetta <ocramius@gmail.com>: > > > On Wed, 24 Apr 2019, 19:10 Christian Schneider, <cschneid@cschneid.com > > > > wrote: > > > Am 24.04.2019 um 19:01 schrieb Peter Kokot <peterkokot@gmail.com>: > > > > just a friendly reminder that by the time one writes an email here > > > > these tags can be already replaced with the usual ones. > > > > > > A friendly reminder that some people are hosting customer code which > > they do not want to touch but will get support requests once the code > > breaks. > > > > > > - Chris > > > > > > That's normal? Everyone has projects to maintain, and breaking changes > > are common: they're gonna call you for one anyway: if you don't like > that, > > then you are in the wrong line of business. > > > > See Chase Peeler's point: A breaking change should have a reward big > > enough to justify it. > > And that's what where we (including Zeev Suraski and other core > > developers) disagree. > > > > - Chris > > > > Run a fixer: they are out there, and they are extremely stable too. > > Also a good chance to finally take a look at code that has been rotting in > a hard drive for too much time. > All of that takes time though. I have 6,787 short opening tags found. Even
if I use a fixer to generate a diff, or, to fix them and then examine the diff in a pull request... that's going to take a LOT of time. It's going to start getting messy if I find false positives and need to exclude changes. It still doesn't address the impact of changes that aren't found. Are you 100% positive that the fixers out there will catch EVERY single instance? php-cs-fixer doesn't update chasepeeler@gmail.com
  105408
April 24, 2019 19:07 peterkokot@gmail.com (Peter Kokot)
Hello,

On Wed, 24 Apr 2019 at 19:44, Chase Peeler <chasepeeler@gmail.com> wrote:
> > On Wed, Apr 24, 2019 at 1:27 PM Marco Pivetta <ocramius@gmail.com> wrote: > > > On Wed, 24 Apr 2019, 19:25 Christian Schneider, <cschneid@cschneid.com> > > wrote: > > > > > Am 24.04.2019 um 19:13 schrieb Marco Pivetta <ocramius@gmail.com>: > > > > On Wed, 24 Apr 2019, 19:10 Christian Schneider, <cschneid@cschneid.com > > > > > > wrote: > > > > Am 24.04.2019 um 19:01 schrieb Peter Kokot <peterkokot@gmail.com>: > > > > > just a friendly reminder that by the time one writes an email here > > > > > these tags can be already replaced with the usual ones. > > > > > > > > A friendly reminder that some people are hosting customer code which > > > they do not want to touch but will get support requests once the code > > > breaks. > > > > > > > > - Chris > > > > > > > > That's normal? Everyone has projects to maintain, and breaking changes > > > are common: they're gonna call you for one anyway: if you don't like > > that, > > > then you are in the wrong line of business. > > > > > > See Chase Peeler's point: A breaking change should have a reward big > > > enough to justify it. > > > And that's what where we (including Zeev Suraski and other core > > > developers) disagree. > > > > > > - Chris > > > > > > > Run a fixer: they are out there, and they are extremely stable too. > > > > Also a good chance to finally take a look at code that has been rotting in > > a hard drive for too much time. > > > All of that takes time though. I have 6,787 short opening tags found. Even > if I use a fixer to generate a diff, or, to fix them and then examine the > diff in a pull request... that's going to take a LOT of time. It's going to > start getting messy if I find false positives and need to exclude changes. > It still doesn't address the impact of changes that aren't found. Are you > 100% positive that the fixers out there will catch EVERY single instance? > php-cs-fixer doesn't update dynamic code, then that's not getting caught. > > The output from php-cs-fixer just generated a diff file that was 161,000 > lines long. But yea, that's something I can scan through real quick and > make sure nothing is going to get broken. No chance I'll miss something > either. > > I would LOVE to have the time to go through our legacy code and clean out > old stuff. We have a lot of technical debt that, while we aren't paying it > off at the moment, it's gaining any interest either. We also have plenty > that is. It's tough to justify putting off the stuff that is gaining > interest to focus on stuff that isn't so we can fix short tags. > > I don't work for a software company. I develop an internal application for > a non-software company. There are 2 other developers and enough work for 10 > developers. It's going to be VERY hard for me to get management to approve > putting off projects that have a direct impact on our business in order to > upgrade to PHP 8 when that time comes. I think you are going to find that's > a pretty common occurrence, and the adoption rate of PHP 8 is going to be > VERY low. Especially when more and more user-friendly alternatives like > python and node are coming along. It was one thing when the options were > RoR, ASP.NET, and JSP. That's not the ecosystem anymore, and it's only > going to provide additional user friendly opportunities in the next couple > of years leading up to PHP8. > > Can someone PLEASE tell me the positive gains this RFC will accomplish that > justifies risking: > 1.) Losing market share > 2.) losing credibility > 3.) removing a large number of libraries that are fine from a technical > aspect, but will stop working due to the existence of 4.) new security risks (code leaks that are more likely than the code leaks > the RFC seeks to prevent) > > And, please don't use the existence of code fixers to justify this unless > you are willing to demonstrate how it's quick and easy to go through a > 161,000 line diff file or are willing to 100% guarantee that the fixer will > not break anything, will not fix anything it shouldn't, and will not miss > anything it should fix. > > > > > > -- > Chase Peeler > chasepeeler@gmail.com
I've done few commits with about 8k files changed with very repeating changes like this and without breaking anything. It will take you about 30minutes... Let's say, one hour for also taking a break from all the scrolling the git diff and to return the merge the next day after another check or something like this. The change (speaking for 8k files using short opening tags converted to
  105409
April 24, 2019 19:30 chasepeeler@gmail.com (Chase Peeler)
On Wed, Apr 24, 2019 at 3:07 PM Peter Kokot <peterkokot@gmail.com> wrote:

> Hello, > > On Wed, 24 Apr 2019 at 19:44, Chase Peeler <chasepeeler@gmail.com> wrote: > > > > On Wed, Apr 24, 2019 at 1:27 PM Marco Pivetta <ocramius@gmail.com> > wrote: > > > > > On Wed, 24 Apr 2019, 19:25 Christian Schneider, <cschneid@cschneid.com > > > > > wrote: > > > > > > > Am 24.04.2019 um 19:13 schrieb Marco Pivetta <ocramius@gmail.com>: > > > > > On Wed, 24 Apr 2019, 19:10 Christian Schneider, < > cschneid@cschneid.com > > > > > > > > wrote: > > > > > Am 24.04.2019 um 19:01 schrieb Peter Kokot <peterkokot@gmail.com>: > > > > > > just a friendly reminder that by the time one writes an email > here > > > > > > these tags can be already replaced with the usual ones. > > > > > > > > > > A friendly reminder that some people are hosting customer code > which > > > > they do not want to touch but will get support requests once the code > > > > breaks. > > > > > > > > > > - Chris > > > > > > > > > > That's normal? Everyone has projects to maintain, and breaking > changes > > > > are common: they're gonna call you for one anyway: if you don't like > > > that, > > > > then you are in the wrong line of business. > > > > > > > > See Chase Peeler's point: A breaking change should have a reward big > > > > enough to justify it. > > > > And that's what where we (including Zeev Suraski and other core > > > > developers) disagree. > > > > > > > > - Chris > > > > > > > > > > Run a fixer: they are out there, and they are extremely stable too. > > > > > > Also a good chance to finally take a look at code that has been > rotting in > > > a hard drive for too much time. > > > > > All of that takes time though. I have 6,787 short opening tags found. > Even > > if I use a fixer to generate a diff, or, to fix them and then examine the > > diff in a pull request... that's going to take a LOT of time. It's going > to > > start getting messy if I find false positives and need to exclude > changes. > > It still doesn't address the impact of changes that aren't found. Are you > > 100% positive that the fixers out there will catch EVERY single instance? > > php-cs-fixer doesn't update > dynamic code, then that's not getting caught. > > > > The output from php-cs-fixer just generated a diff file that was 161,000 > > lines long. But yea, that's something I can scan through real quick and > > make sure nothing is going to get broken. No chance I'll miss something > > either. > > > > I would LOVE to have the time to go through our legacy code and clean out > > old stuff. We have a lot of technical debt that, while we aren't paying > it > > off at the moment, it's gaining any interest either. We also have plenty > > that is. It's tough to justify putting off the stuff that is gaining > > interest to focus on stuff that isn't so we can fix short tags. > > > > I don't work for a software company. I develop an internal application > for > > a non-software company. There are 2 other developers and enough work for > 10 > > developers. It's going to be VERY hard for me to get management to > approve > > putting off projects that have a direct impact on our business in order > to > > upgrade to PHP 8 when that time comes. I think you are going to find > that's > > a pretty common occurrence, and the adoption rate of PHP 8 is going to be > > VERY low. Especially when more and more user-friendly alternatives like > > python and node are coming along. It was one thing when the options were > > RoR, ASP.NET, and JSP. That's not the ecosystem anymore, and it's only > > going to provide additional user friendly opportunities in the next > couple > > of years leading up to PHP8. > > > > Can someone PLEASE tell me the positive gains this RFC will accomplish > that > > justifies risking: > > 1.) Losing market share > > 2.) losing credibility > > 3.) removing a large number of libraries that are fine from a technical > > aspect, but will stop working due to the existence of > 4.) new security risks (code leaks that are more likely than the code > leaks > > the RFC seeks to prevent) > > > > And, please don't use the existence of code fixers to justify this unless > > you are willing to demonstrate how it's quick and easy to go through a > > 161,000 line diff file or are willing to 100% guarantee that the fixer > will > > not break anything, will not fix anything it shouldn't, and will not miss > > anything it should fix. > > > > > > > > > > > > -- > > Chase Peeler > > chasepeeler@gmail.com > > I've done few commits with about 8k files changed with very repeating > changes like this and without breaking anything. It will take you > about 30minutes... Let's say, one hour for also taking a break from > all the scrolling the git diff and to return the merge the next day > after another check or something like this. > > The change (speaking for 8k files using short opening tags converted > to the memory_limit needs to be increased a bit and only relevant change > is done in all files. 8k (or 6k) opening tags is nothing very big > actually. > > Honestly, the amount of people that have never seen or worked with my codebase telling me how easy and low risk it will be to make the change are
starting to annoy me. Can even one of you actually address any of the points I've made about why the potential negatives of this change far outweigh any potential positives? Heck, can you even present any potential positives?
> Then also search for similar occurrences by using a regex for those > edge cases you're mentioning in strings and such (I doubt there are > but ok) and you have this fixed. Then run this app on PHP 8 and you'll > see the other BC breaks that happen due to the major release. Major > releases are meant to break things because otherwise we can only load > the language with new things and maintain old stuff in there for > eternity. > > As I've said before - I have no issue with BC breaks. What I have an issue with is a BC break that has a large potential for negative consequences
that aren't anywhere close to being outweighed by the positive ones. None of the reasons presented in the RFC justify the downsides. Not a single person has addressed any of the potential negatives being brought up, either. They just respond that it's easy to update your code and pretend like there isn't a potential for negative consequences.
> That's why serious apps have support cycles and follow their > frameworks release and life cycle, and in the end also PHP cycle. > Simple as that. > > I work on an internal application for a non-software company. We are beholden to the cycles of our business. We try and work in upgrades when
it's possible and we have a lull between major projects or when we can justify delaying a project in order to perform an upgrade.
> -- > Peter Kokot > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Unless someone decides to actually discuss the issues I've raised in previous emails, instead of just telling me how easy it's going to be for
me to update my codebase that they know nothing about, this will be the last message I'm sending in this thread. -- Chase Peeler chasepeeler@gmail.com
  105428
April 25, 2019 00:19 info@phpgangsta.de (Michael Kliewe)
Hi there,

Am 24.04.2019 um 21:07 schrieb Peter Kokot:
> Hello, > > On Wed, 24 Apr 2019 at 19:44, Chase Peeler <chasepeeler@gmail.com> wrote: >> On Wed, Apr 24, 2019 at 1:27 PM Marco Pivetta <ocramius@gmail.com> wrote: >> >>> Run a fixer: they are out there, and they are extremely stable too. >>> >>> Also a good chance to finally take a look at code that has been rotting in >>> a hard drive for too much time. >>> >> All of that takes time though. I have 6,787 short opening tags found. Even >> if I use a fixer to generate a diff, or, to fix them and then examine the >> diff in a pull request... that's going to take a LOT of time. It's going to >> start getting messy if I find false positives and need to exclude changes. >> It still doesn't address the impact of changes that aren't found. Are you >> 100% positive that the fixers out there will catch EVERY single instance? >> php-cs-fixer doesn't update > dynamic code, then that's not getting caught. >> >> The output from php-cs-fixer just generated a diff file that was 161,000 >> lines long. But yea, that's something I can scan through real quick and >> make sure nothing is going to get broken. No chance I'll miss something >> either. >> >> I would LOVE to have the time to go through our legacy code and clean out >> old stuff. We have a lot of technical debt that, while we aren't paying it >> off at the moment, it's gaining any interest either. We also have plenty >> that is. It's tough to justify putting off the stuff that is gaining >> interest to focus on stuff that isn't so we can fix short tags. >> >> I don't work for a software company. I develop an internal application for >> a non-software company. There are 2 other developers and enough work for 10 >> developers. It's going to be VERY hard for me to get management to approve >> putting off projects that have a direct impact on our business in order to >> upgrade to PHP 8 when that time comes. I think you are going to find that's >> a pretty common occurrence, and the adoption rate of PHP 8 is going to be >> VERY low. Especially when more and more user-friendly alternatives like >> python and node are coming along. It was one thing when the options were >> RoR, ASP.NET, and JSP. That's not the ecosystem anymore, and it's only >> going to provide additional user friendly opportunities in the next couple >> of years leading up to PHP8. >> >> Can someone PLEASE tell me the positive gains this RFC will accomplish that >> justifies risking: >> 1.) Losing market share >> 2.) losing credibility >> 3.) removing a large number of libraries that are fine from a technical >> aspect, but will stop working due to the existence of > 4.) new security risks (code leaks that are more likely than the code leaks >> the RFC seeks to prevent) >> >> And, please don't use the existence of code fixers to justify this unless >> you are willing to demonstrate how it's quick and easy to go through a >> 161,000 line diff file or are willing to 100% guarantee that the fixer will >> not break anything, will not fix anything it shouldn't, and will not miss >> anything it should fix. >> >> >> >> >> >> -- >> Chase Peeler >> chasepeeler@gmail.com > I've done few commits with about 8k files changed with very repeating > changes like this and without breaking anything. It will take you > about 30minutes... Let's say, one hour for also taking a break from > all the scrolling the git diff and to return the merge the next day > after another check or something like this. > > The change (speaking for 8k files using short opening tags converted > to the memory_limit needs to be increased a bit and only relevant change > is done in all files. 8k (or 6k) opening tags is nothing very big > actually. > > Then also search for similar occurrences by using a regex for those > edge cases you're mentioning in strings and such (I doubt there are > but ok) and you have this fixed. Then run this app on PHP 8 and you'll > see the other BC breaks that happen due to the major release. Major > releases are meant to break things because otherwise we can only load > the language with new things and maintain old stuff in there for > eternity. > > That's why serious apps have support cycles and follow their > frameworks release and life cycle, and in the end also PHP cycle. > Simple as that. > > -- > Peter Kokot
Some thoughts and numbers from my side. Nobody should not use a simple grep or sed like this: grep -rin "php:97: $start=0;$end=strpos($res,"php:1:php:67:        Text:
../scripts/XXXupload.php:68:        Text2:
Binary file ./library/phpillow/tests/phpillow/data/image_gif.gif matches Binary file ../library/phpillow/tests/phpillow/data/.svn/text-base/image_gif.gif.svn-base matches ../library/ezcomponents/Mail/src/tools.php:225:        $pattern = '/?$/'; ../library/XXXX/SoapApi.php:1: result.txt Reviewing these 51 changes took 3 minutes. No false positives here, all of them were at the beginning of files. BUT: it didn't search in .phtml files. php-cs-fixer by default only processes .php and .phpt files (depending on the version you are using, older versions also process .twig files as far as I can see). If you use it, you may have to add other file extensions like .phtml, .tpl or similar, depending on your project. Running php-cs-fixer on .phtml files in that project results in a diff file with 9527 lines, 1573 line changes just in the .phtml files of that project. Whao... I'm not sure if I'm alone, but I have lots of template code like this:
Xdata as $index => $data) { ?>        
Something
Blindly replacing " Xdata as $index => $data) { ?>        
Something
The nice visual indenting of the "foreach" with 4 spaces is broken now, and cannot be fixed, because "
  105529
April 30, 2019 20:23 bishop@php.net (Bishop Bettini)
On Wed, Apr 24, 2019 at 8:19 PM Michael Kliewe <info@phpgangsta.de> wrote:

> Some random thoughts: > - What happens to .phar files? Do we have to scan the contents? >
Phar relies upon the engine's tokenizer. If your phar build script uses createDefaultStub('index.php'); $phar->setStub($stub); $ php -d phar.readonly=Off create-test.phar.php $ php -d short_open_tag=On test.phar I am a short tag $ php -d short_open_tag=Off test.phar
  105413
April 24, 2019 21:12 bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)
Den 2019-04-24 kl. 19:43, skrev Chase Peeler:
> On Wed, Apr 24, 2019 at 1:27 PM Marco Pivetta <ocramius@gmail.com> wrote: > >> On Wed, 24 Apr 2019, 19:25 Christian Schneider, <cschneid@cschneid.com> >> wrote: >> >>> Am 24.04.2019 um 19:13 schrieb Marco Pivetta <ocramius@gmail.com>: >>>> On Wed, 24 Apr 2019, 19:10 Christian Schneider, <cschneid@cschneid.com >>> wrote: >>>> Am 24.04.2019 um 19:01 schrieb Peter Kokot <peterkokot@gmail.com>: >>>>> just a friendly reminder that by the time one writes an email here >>>>> these tags can be already replaced with the usual ones. >>>> A friendly reminder that some people are hosting customer code which >>> they do not want to touch but will get support requests once the code >>> breaks. >>>> - Chris >>>> >>>> That's normal? Everyone has projects to maintain, and breaking changes >>> are common: they're gonna call you for one anyway: if you don't like >> that, >>> then you are in the wrong line of business. >>> >>> See Chase Peeler's point: A breaking change should have a reward big >>> enough to justify it. >>> And that's what where we (including Zeev Suraski and other core >>> developers) disagree. >>> >>> - Chris >>> >> Run a fixer: they are out there, and they are extremely stable too. >> >> Also a good chance to finally take a look at code that has been rotting in >> a hard drive for too much time. >> > All of that takes time though. I have 6,787 short opening tags found. Even > if I use a fixer to generate a diff, or, to fix them and then examine the > diff in a pull request... that's going to take a LOT of time. It's going to > start getting messy if I find false positives and need to exclude changes. > It still doesn't address the impact of changes that aren't found. Are you > 100% positive that the fixers out there will catch EVERY single instance? > php-cs-fixer doesn't update dynamic code, then that's not getting caught. > > The output from php-cs-fixer just generated a diff file that was 161,000 > lines long. But yea, that's something I can scan through real quick and > make sure nothing is going to get broken. No chance I'll miss something > either. > > I would LOVE to have the time to go through our legacy code and clean out > old stuff. We have a lot of technical debt that, while we aren't paying it > off at the moment, it's gaining any interest either. We also have plenty > that is. It's tough to justify putting off the stuff that is gaining > interest to focus on stuff that isn't so we can fix short tags. > > I don't work for a software company. I develop an internal application for > a non-software company. There are 2 other developers and enough work for 10 > developers. It's going to be VERY hard for me to get management to approve > putting off projects that have a direct impact on our business in order to > upgrade to PHP 8 when that time comes. I think you are going to find that's > a pretty common occurrence, and the adoption rate of PHP 8 is going to be > VERY low. Especially when more and more user-friendly alternatives like > python and node are coming along. It was one thing when the options were > RoR, ASP.NET, and JSP. That's not the ecosystem anymore, and it's only > going to provide additional user friendly opportunities in the next couple > of years leading up to PHP8. > > Can someone PLEASE tell me the positive gains this RFC will accomplish that > justifies risking: > 1.) Losing market share > 2.) losing credibility > 3.) removing a large number of libraries that are fine from a technical > aspect, but will stop working due to the existence of 4.) new security risks (code leaks that are more likely than the code leaks > the RFC seeks to prevent)
Hi, I did a quick check on two open source libraries that I'm using, namely Smarty templating library and Revive ad server. A quick glance at hand shows that they both uses the
  105415
April 24, 2019 21:38 peterkokot@gmail.com (Peter Kokot)
Hello,

On Wed, 24 Apr 2019 at 23:12, Björn Larsson larsson@telia.com> wrote:
> Hi, > > I did a quick check on two open source libraries that I'm using, > namely Smarty templating library and Revive ad server. A quick > glance at hand shows that they both uses the latest release. Smarty 3.1.33 was released 17/9 2018 and > Revive 4.2.0 was released 23/4 2019. > > It would be interesting to see if there is any benefit in fixing this > feature for these two well-established libraries? I think that both > these libraries will adapt, but how long will it take... Regarding > your points above I don't see any added value that this feature > brings for me as a user of these two libraries, since I'm quite > happy with the functionality they provide as is. How then the > developers see it is not up to me to judge. > > r//Björn L >
I'm not sure if we're looking at the same libraries and versions here but both of these use normal opening tags in the code for quite a while: https://github.com/revive-adserver/revive-adserver https://github.com/smarty-php/smarty Keywords open source, PHP, and short opening tags don't go together anymore neither people coding in PHP are using these anymore for a very long time. If they postpone upgrades and neglect good coding practices, nothing can help them improve or fix their apps. -- Peter Kokot
  105417
April 24, 2019 22:07 bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)
Den 2019-04-24 kl. 23:38, skrev Peter Kokot:
> Hello, > > On Wed, 24 Apr 2019 at 23:12, Björn Larsson larsson@telia.com> wrote: >> Hi, >> >> I did a quick check on two open source libraries that I'm using, >> namely Smarty templating library and Revive ad server. A quick >> glance at hand shows that they both uses the > latest release. Smarty 3.1.33 was released 17/9 2018 and >> Revive 4.2.0 was released 23/4 2019. >> >> It would be interesting to see if there is any benefit in fixing this >> feature for these two well-established libraries? I think that both >> these libraries will adapt, but how long will it take... Regarding >> your points above I don't see any added value that this feature >> brings for me as a user of these two libraries, since I'm quite >> happy with the functionality they provide as is. How then the >> developers see it is not up to me to judge. >> >> r//Björn L >> > I'm not sure if we're looking at the same libraries and versions here > but both of these use normal opening tags in the code for quite a > while: > https://github.com/revive-adserver/revive-adserver > https://github.com/smarty-php/smarty > > Keywords open source, PHP, and short opening tags don't go together > anymore neither people coding in PHP are using these anymore for a > very long time. If they postpone upgrades and neglect good coding > practices, nothing can help them improve or fix their apps.
Well, checking a bit closer when running the script: grep -rin "
  105416
April 24, 2019 21:46 lester@lsces.co.uk (Lester Caine)
On 24/04/2019 22:12, Björn Larsson wrote:
> I did a quick check on two open source libraries that I'm using, > namely Smarty templating library and Revive ad server. A quick > glance at hand shows that they both uses the latest release. Smarty 3.1.33 was released 17/9 2018 and > Revive 4.2.0 was released 23/4 2019. > > It would be interesting to see if there is any benefit in fixing this > feature for these two well-established libraries?
At the same time fixes for the PHP7.2 warnings would be helpful! My templates keep throwing 'count' warnings which currently have been fixed by simply removing the 'count' and leaving the value blank. That is until someone who knows how to fix it provides a fix. It's BUILDING cached templates which can't simply be sanitised by scanning the code base! -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
  105422
April 24, 2019 23:30 cmbecker69@gmx.de ("Christoph M. Becker")
On 24.04.2019 at 23:46, Lester Caine wrote:

> At the same time fixes for the PHP7.2 warnings would be helpful! My > templates keep throwing 'count' warnings which currently have been fixed > by simply removing the 'count' and leaving the value blank. That is > until someone who knows how to fix it provides a fix. It's BUILDING > cached templates which can't simply be sanitised by scanning the code base!
I don't think this belongs to the internals mailing list, so see <http://news.php.net/php.general/326733>. -- Christoph M. Becker
  105427
April 25, 2019 00:05 lester@lsces.co.uk (Lester Caine)
On 25/04/2019 00:30, Christoph M. Becker wrote:
>> At the same time fixes for the PHP7.2 warnings would be helpful! My >> templates keep throwing 'count' warnings which currently have been fixed >> by simply removing the 'count' and leaving the value blank. That is >> until someone who knows how to fix it provides a fix. It's BUILDING >> cached templates which can't simply be sanitised by scanning the code base!
> I don't think this belongs to the internals mailing list, so see > <http://news.php.net/php.general/326733>.
If *I* was using count then that sort of fix would work. The problem is in the way SMARTY handles adding 'count' of a smarty variable in a template ... and certainly I have https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
  105520
April 30, 2019 17:31 php@beccati.com (Matteo Beccati)
Hi Björn,

On 24/04/2019 23:12, Björn Larsson wrote:
> I did a quick check on two open source libraries that I'm using, > namely Smarty templating library and Revive ad server. A quick > glance at hand shows that they both uses the latest release. Smarty 3.1.33 was released 17/9 2018 and > Revive 4.2.0 was released 23/4 2019.
I voted yes, even knowing that I'd have to do some extra OSS work. Short open tags have been banned possibly 13 years ago in the project coding standards, but there might still be some leftovers. I'll make sure that will be corrected soon for Revive and its bundled Smarty lib fork. Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/
  105402
April 24, 2019 18:08 r@roze.lv ("Reinis Rozitis")
> -----Original Message----- > From: Marco Pivetta [mailto:ocramius@gmail.com] > > Also a good chance to finally take a look at code that has been rotting in a hard > drive for too much time.
It's an odd way of justifying a BC break by saying "you can write this one-liner sed or use this third-party tool to alter you code" exactly the same way every backwards incompatible change can be fixed then .. and then it makes no sense to even discuss. At the beginning of the proposal it was asked (on mailinglist) if the change has any impact on performance (php runs faster/language parses becomes substantially simple etc), if there are any security issues (like with magic quotes) or maybe similarly as with different extensions there is no one to support the code anymore. But in the end there is only the '
  105404
April 24, 2019 18:20 bogus@news.php.net (Unknown Sender)
Hi,

>Also imo the reason why people write now (and not in the discussion phase) because for some time in the voting there wasn't the 2/3 majority for the 7.4 (so no sense to clutter the list) and now in the end only 1-2 votes make the difference.
If this RFC has caused such a resonance _after_ the vote, maybe, it can be reopened for a few days so that those who have not voted can do it? Thus, it is not the "1-2 votes" that will matter. — Sincerely, Sergey Panteleev On 24 Apr 2019, 21:08 +0300, Reinis Rozitis <r@roze.lv>, wrote:
> > -----Original Message----- > > From: Marco Pivetta [mailto:ocramius@gmail.com] > > > > Also a good chance to finally take a look at code that has been rotting in a hard > > drive for too much time. > > It's an odd way of justifying a BC break by saying "you can write this one-liner sed or use this third-party tool to alter you code" exactly the same way every backwards incompatible change can be fixed then .. and then it makes no sense to even discuss. > > At the beginning of the proposal it was asked (on mailinglist) if the change has any impact on performance (php runs faster/language parses becomes substantially simple etc), if there are any security issues (like with magic quotes) or maybe similarly as with different extensions there is no one to support the code anymore. > > But in the end there is only the ' > So instead of by default disabling it and allowing the users make an conscious choice to reenable the option if needed it's removed altogether. > > > > Also imo the reason why people write now (and not in the discussion phase) because for some time in the voting there wasn't the 2/3 majority for the 7.4 (so no sense to clutter the list) and now in the end only 1-2 votes make the difference. > > rr > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
  105405
April 24, 2019 18:22 chasepeeler@gmail.com (Chase Peeler)
On Wed, Apr 24, 2019 at 2:20 PM Сергей Пантелеев <sergey@s-panteleev.ru>
wrote:

> Hi, > > >Also imo the reason why people write now (and not in the discussion > phase) because for some time in the voting there wasn't the 2/3 majority > for the 7.4 (so no sense to clutter the list) and now in the end only 1-2 > votes make the difference. > > If this RFC has caused such a resonance _after_ the vote, maybe, it can be > reopened for a few days so that those who have not voted can do it? > > Thus, it is not the "1-2 votes" that will matter. > I think a lot of the people speaking against it, both before and after,
don’t get a vote. I think the people that this is going to have the biggest negative impact on are the developers out there that don’t even know this mailing lists exists, much less this RFC or discussion.
> — > Sincerely, > Sergey Panteleev > On 24 Apr 2019, 21:08 +0300, Reinis Rozitis <r@roze.lv>, wrote: > > > -----Original Message----- > > > From: Marco Pivetta [mailto:ocramius@gmail.com] > > > > > > Also a good chance to finally take a look at code that has been > rotting in a hard > > > drive for too much time. > > > > It's an odd way of justifying a BC break by saying "you can write this > one-liner sed or use this third-party tool to alter you code" exactly the > same way every backwards incompatible change can be fixed then .. and then > it makes no sense to even discuss. > > > > At the beginning of the proposal it was asked (on mailinglist) if the > change has any impact on performance (php runs faster/language parses > becomes substantially simple etc), if there are any security issues (like > with magic quotes) or maybe similarly as with different extensions there is > no one to support the code anymore. > > > > But in the end there is only the ' documentation discourages short tags because that’s ini specific (while > there are bunch of other ini directives which change the the way php works > (like for example precision)) .. and that's it. > > > > So instead of by default disabling it and allowing the users make an > conscious choice to reenable the option if needed it's removed altogether.. > > > > > > > > Also imo the reason why people write now (and not in the discussion > phase) because for some time in the voting there wasn't the 2/3 majority > for the 7.4 (so no sense to clutter the list) and now in the end only 1-2 > votes make the difference. > > > > rr > > > > > > > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > --
Chase Peeler chasepeeler@gmail.com
  105406
April 24, 2019 18:51 mo.mu.wss@gmail.com ("M. W. Moe")
Hello,

just deprecate it; please stop this load of nonsense; it's not even a
rational discussion here; that's a lot of idiotic rumblings.

Have a good day.

On Wed, Apr 24, 2019 at 11:23 AM Chase Peeler <chasepeeler@gmail.com> wrote:

> On Wed, Apr 24, 2019 at 2:20 PM Сергей Пантелеев <sergey@s-panteleev.ru> > wrote: > > > Hi, > > > > >Also imo the reason why people write now (and not in the discussion > > phase) because for some time in the voting there wasn't the 2/3 majority > > for the 7.4 (so no sense to clutter the list) and now in the end only 1-2 > > votes make the difference. > > > > If this RFC has caused such a resonance _after_ the vote, maybe, it can > be > > reopened for a few days so that those who have not voted can do it? > > > > Thus, it is not the "1-2 votes" that will matter. > > > I think a lot of the people speaking against it, both before and after, > don’t get a vote. > > I think the people that this is going to have the biggest negative impact > on are the developers out there that don’t even know this mailing lists > exists, much less this RFC or discussion. > > > > — > > Sincerely, > > Sergey Panteleev > > On 24 Apr 2019, 21:08 +0300, Reinis Rozitis <r@roze.lv>, wrote: > > > > -----Original Message----- > > > > From: Marco Pivetta [mailto:ocramius@gmail.com] > > > > > > > > Also a good chance to finally take a look at code that has been > > rotting in a hard > > > > drive for too much time. > > > > > > It's an odd way of justifying a BC break by saying "you can write this > > one-liner sed or use this third-party tool to alter you code" exactly the > > same way every backwards incompatible change can be fixed then .. and > then > > it makes no sense to even discuss. > > > > > > At the beginning of the proposal it was asked (on mailinglist) if the > > change has any impact on performance (php runs faster/language parses > > becomes substantially simple etc), if there are any security issues (like > > with magic quotes) or maybe similarly as with different extensions there > is > > no one to support the code anymore. > > > > > > But in the end there is only the ' > documentation discourages short tags because that’s ini specific (while > > there are bunch of other ini directives which change the the way php > works > > (like for example precision)) .. and that's it. > > > > > > So instead of by default disabling it and allowing the users make an > > conscious choice to reenable the option if needed it's removed > altogether. > > > > > > > > > > > > Also imo the reason why people write now (and not in the discussion > > phase) because for some time in the voting there wasn't the 2/3 majority > > for the 7.4 (so no sense to clutter the list) and now in the end only 1-2 > > votes make the difference. > > > > > > rr > > > > > > > > > > > > > > > -- > > > PHP Internals - PHP Runtime Development Mailing List > > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > -- > Chase Peeler > chasepeeler@gmail.com >
  105418
April 24, 2019 22:09 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> If this RFC has caused such a resonance _after_ the vote, maybe, it > can be reopened for a few days so that those who have not voted can > do it?
These concerns were expressed before the vote too. They were thoroughly ignored. That didn't make them disappear. -- Stas Malyshev smalyshev@gmail.com
  105478
April 28, 2019 08:01 zeev@php.net (Zeev Suraski)
On Wed, Apr 24, 2019 at 9:08 PM Reinis Rozitis <r@roze.lv> wrote:

> Also imo the reason why people write now (and not in the discussion > phase) because for some time in the voting there wasn't the 2/3 majority > for the 7.4 (so no sense to clutter the list) and now in the end only 1-2 > votes make the difference. > > At least for me, this definitely was the case. When I voted, it was
nowhere near clearing the 2/3 threshold. As I said numerous times in the past, I'm a firm believer that controversial RFCs (ones that generate a lot of votes with a substantial number of opposers) should not pass. I think this is important when adding features - but it's actually a lot more important with deprecations. When there's substantial doubt whether a deprecation should go through or not, there should be no doubt at all - it shouldn't. This is one of the clearest cases if not the clearest one we've had to date. Process wise we're in a bit of an unchartered territory here, but I don't think we should let the headache involved with figuring out how to reverse this decision force us to impose this on our users. It's better to go through this unpleasantry now than deal with the backlash later. George, please consider reopening the vote for an extra week. That is probably the simplest way to move forward from a process standpoint. Zeev
  105479
April 28, 2019 11:26 george.banyard@gmail.com ("G. P. B.")
On Sun, 28 Apr 2019 at 10:01, Zeev Suraski <zeev@php.net> wrote:

> On Wed, Apr 24, 2019 at 9:08 PM Reinis Rozitis <r@roze.lv> wrote: > > > Also imo the reason why people write now (and not in the discussion > > phase) because for some time in the voting there wasn't the 2/3 majority > > for the 7.4 (so no sense to clutter the list) and now in the end only 1-2 > > votes make the difference. > > > > > At least for me, this definitely was the case. When I voted, it was > nowhere near clearing the 2/3 threshold. >
You must have voted on the same day the RFC went to voting. As the next day when I had a chat with Derick for his podcast both votes had cleared the 2/3 threshold, not with a big supra-majority but it cleared. And it was above the threshold for the rest of the voting period everytime I checked (so mas every two days). So are we now going to need to do daily email during the vote to inform what is the voting status of our RFC so everyone is in the loop? When you can simply just check the RFC page or look at PHP RFC Watch? [1]
> As I said numerous times in the past, I'm a firm believer that > controversial RFCs (ones that generate a lot of votes with a substantial > number of opposers) should not pass. I think this is important when adding > features - but it's actually a lot more important with deprecations. When > there's substantial doubt whether a deprecation should go through or not, > there should be no doubt at all - it shouldn't. This is one of the > clearest cases if not the clearest one we've had to date. >
This IMHO applies to the deprecation vote which includes the default change (and seems that is where people disagree as more people vote for the removal without the deprecation notices which seems to point this is the issue) which in hindsight is a stupid thing to do, but I would have loved that people point out to this specific issue (and the voting structure) during the discussion or even at the beginning of the vote. But basing my self on the vote to remove the short open tags in PHP 8, which cleared with 74% so nearly 3/4 it would need six (6) more "NO" votes without any "YES" votes to be on the 2/3 threshold. Whereas the deprecation votes "only" needs two (2) votes to be on the 2/3 threshold. So to my understanding of how the RFC process works there would need to be at least three (3) "NO" votes for the deprecation to fail (which I think we can all agree how I went about is crap and I'm open to changing how this gets implemented as seen on the other ML thread and the PR) and at least seven (7) "NO" votes for the removal vote. Process wise we're in a bit of an unchartered territory here, but I don't
> think we should let the headache involved with figuring out how to reverse > this decision force us to impose this on our users. It's better to go > through this unpleasantry now than deal with the backlash later. >
I mean I don't see how we are in unchartered territory, the vote passed, sure with not a huge supra majority but it still passed. Moreover going about how Twitter [2] reacted (which isn't necessarely a good metric) it seems a *vast* majority is in favor of this change.
> George, please consider reopening the vote for an extra week. That is > probably the simplest way to move forward from a process standpoint. > > Zeev >
I can consider it but I am really not keen on it. Because what prevent me from then re-openning the vote again if the vote then fails? What happens if the deprecation vote fails but not the removal? Would this imply changing how it is deprecated which is literally the topic of the other thread without any more voting which I'm totally open to how it is changed? I don't even mind still having a compile error in PHP 8 when it sees the token as I said before I don't really care that much about the timeline. Best regards George P. Banyard [1] https://php-rfc-watch.beberlei.de/ [2] https://twitter.com/nikita_ppv/status/1121040700156579840
  105480
April 28, 2019 11:52 benjamin.morel@gmail.com (Benjamin Morel)
> I don't even mind still having a compile error in PHP 8 when it sees the token
I don't have a vote so these are just my 2 cents, but even though I'm all for removing short open tags entirely, I think that this solution is excellent for 2 reasons: - it solves the code leak issue when upgrading blindly from PHP 7 to PHP 8, and still makes short open tags effectively unusable on PHP 8; it can therefore make everyone confident that they can then be removed in PHP 9, as the odds of someone upgrading blindly from PHP 7 to PHP 9 are almost nonexistent - it allows tools that automatically convert short open tags to standard open tags to actually work on PHP 8. Because if I'm not mistaken, if these tools are based on token_get_all() and "
  105482
April 28, 2019 13:51 thruska@cubiclesoft.com (Thomas Hruska)
On 4/28/2019 4:52 AM, Benjamin Morel wrote:
> - it allows tools that automatically convert short open tags to standard > open tags to actually work on PHP 8. Because if I'm not mistaken, if these > tools are based on token_get_all() and " anymore in PHP 8, these tools would stop working on PHP 8.
It's very much possible to use token_get_all() with short open tag support disabled and/or removed to convert from short open tags to full open tags and, in fact, has already been done. -- 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/
  105486
April 28, 2019 19:46 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

On 4/28/19 4:52 AM, Benjamin Morel wrote:
>> I don't even mind still having a compile error in PHP 8 when it sees the > token
I thought one of the arguments for the whole enterprise was to enable smalyshev@gmail.com
  105481
April 28, 2019 12:35 zeev@php.net (Zeev Suraski)
On Sun, Apr 28, 2019 at 2:27 PM G. P. B. banyard@gmail.com> wrote:

> On Sun, 28 Apr 2019 at 10:01, Zeev Suraski <zeev@php.net> wrote: > >> On Wed, Apr 24, 2019 at 9:08 PM Reinis Rozitis <r@roze.lv> wrote: >> >> > Also imo the reason why people write now (and not in the discussion >> > phase) because for some time in the voting there wasn't the 2/3 majority >> > for the 7.4 (so no sense to clutter the list) and now in the end only >> 1-2 >> > votes make the difference. >> > >> > >> At least for me, this definitely was the case. When I voted, it was >> nowhere near clearing the 2/3 threshold. >> > > You must have voted on the same day the RFC went to voting. >
That's definitely possible. I don't really remember, even though I do remember there were more than a handful of votes already registered.
> As the next day when I had a chat with Derick for his podcast both votes > had cleared the 2/3 threshold, not with a big supra-majority but it > cleared. > And it was above the threshold for the rest of the voting period everytime > I > checked (so mas every two days). > So are we now going to need to do daily email during the vote to inform > what is the voting status of our RFC so everyone is in the loop? When > you can simply just check the RFC page or look at PHP RFC Watch? [1] >
I think a 24hr reminder going to internals is probably not a bad idea, but that's beyond the scope of this discussion and it's obviously not your fault for not sending it, considering one was never required.
> As I said numerous times in the past, I'm a firm believer that >> controversial RFCs (ones that generate a lot of votes with a substantial >> number of opposers) should not pass. I think this is important when >> adding >> features - but it's actually a lot more important with deprecations. When >> there's substantial doubt whether a deprecation should go through or not, >> there should be no doubt at all - it shouldn't. This is one of the >> clearest cases if not the clearest one we've had to date. >> > > This IMHO applies to the deprecation vote which includes the default change >
From my POV it applies to all deprecations, although obviously taking out something that's been a basic building block for the last 20+ years is probably more of an issue than some 3rd party utility function. (and seems that is where people disagree as more people vote for the removal
> without the deprecation notices which seems to point this is the issue) > which in hindsight is a stupid thing to do, but I would have loved that > people > point out to this specific issue (and the voting structure) during the > discussion > or even at the beginning of the vote. > > But basing my self on the vote to remove the short open tags in PHP 8, > which > cleared with 74% so nearly 3/4 it would need six (6) more "NO" votes > without any > "YES" votes to be on the 2/3 threshold. Whereas the deprecation votes > "only" > needs two (2) votes to be on the 2/3 threshold. >
That's not how I understood the vote - although honestly, I found the vote layout to be a bit weird. There are are two issues here: 1. Secondary votes only kick in if the primary vote passes. They're also defined as votes where you only need a simple majority for one of the options. 2. The two questions are, in fact, one and the same. Removing a feature in a major version requires that we first deprecate it in a mini version, in other words - we can't remove something in 8.0 in case it's not first deprecated in 7.4. I admit I found this confusing that the two votes were separate, but the way I understood it, is that we may actually deprecate it at 7.4, without actually removing it at 8.0, but just keeping it deprecated. The other way around (removing it in 8.0 without first deprecating it in 7.x) is against our rules. I mean I don't see how we are in unchartered territory, the vote passed,
> sure > with not a huge supra majority but it still passed. >
We're in unchartered territory not from a process perspective, but in terms of the number of core devs who think it's a really bad idea and the fact we're rediculously close to the minimum threshold - for something that should really happen with consensus.
> Moreover going about how Twitter [2] reacted (which isn't necessarely a > good > metric) it seems a *vast* majority is in favor of this change. >
It is, indeed, not a very good or even meaningful metric at all. The folks which are likely to care about this are almost definitely severely under-represented both here and on the dev cycles on Twitter.
> I can consider it but I am really not keen on it. >
I'd sincrerely appreciate it if you did. I'm not fond of fighting windmills, even less so nowadays than in the past - but I really think we're making a painful mistake for virtually no gain, and I'm pretty sure I'm not alone in thinking that. Ultimately, nothing in the RFC is new compared to what we knew back in 1998 when we decided to have short open tags. There are no new developments that make it more relevant today than it was back then - if anything, XML is a lot less important today than it was back then (when it was all the rage). And unlike 1998, the cost assocaited with deprecating it now is tremendous. So even if we can argue whether we took the right decision 20 years ago - there's really no new grounds to reopen that decision today. Because what prevent me from then re-openning the vote again if the vote
> then fails? >
Nothing really, other than common courtesy. I was even hoping that the RFC will be withdrawn given the number of nays from core devs, but that's of course something that is up to you. What happens if the deprecation vote fails but not the removal?
> Would this imply changing how it is deprecated which is literally the topic
> of the > other thread without any more voting which I'm totally open to how it is > changed? > > I don't even mind still having a compile error in PHP 8 when it sees the > token > as I said before I don't really care that much about the timeline. >
I think the real question this RFC raises is whether we want to deprecate
  105487
April 28, 2019 20:30 george.banyard@gmail.com ("G. P. B.")
On Sun, 28 Apr 2019 at 14:36, Zeev Suraski <zeev@php.net> wrote:

> As I said numerous times in the past, I'm a firm believer that >>> controversial RFCs (ones that generate a lot of votes with a substantial >>> number of opposers) should not pass. I think this is important when >>> adding >>> features - but it's actually a lot more important with deprecations. >>> When >>> there's substantial doubt whether a deprecation should go through or not, >>> there should be no doubt at all - it shouldn't. This is one of the >>> clearest cases if not the clearest one we've had to date. >>> >> >> This IMHO applies to the deprecation vote which includes the default >> change >> > > From my POV it applies to all deprecations, although obviously taking out > something that's been a basic building block for the last 20+ years is > probably more of an issue than some 3rd party utility function. >
I think this just boils down to what is an acceptable majority, if 2/3 is not enough then 3/4 but this is another debate altogether. (and seems that is where people disagree as more people vote for the removal
>> without the deprecation notices which seems to point this is the issue) >> which in hindsight is a stupid thing to do, but I would have loved that >> people >> point out to this specific issue (and the voting structure) during the >> discussion >> or even at the beginning of the vote. >> >> But basing my self on the vote to remove the short open tags in PHP 8, >> which >> cleared with 74% so nearly 3/4 it would need six (6) more "NO" votes >> without any >> "YES" votes to be on the 2/3 threshold. Whereas the deprecation votes >> "only" >> needs two (2) votes to be on the 2/3 threshold. >> > > That's not how I understood the vote - although honestly, I found the vote > layout to be a bit weird. > > There are are two issues here: > 1. Secondary votes only kick in if the primary vote passes. They're also > defined as votes where you only need a simple majority for one of the > options. > 2. The two questions are, in fact, one and the same. Removing a feature > in a major version requires that we first deprecate it in a mini version, > in other words - we can't remove something in 8.0 in case it's not first > deprecated in 7.4. > > I admit I found this confusing that the two votes were separate, but the > way I understood it, is that we may actually deprecate it at 7.4, without > actually removing it at 8.0, but just keeping it deprecated. The other way > around (removing it in 8.0 without first deprecating it in 7.x) is against > our rules. >
This was indeed the intention of the voting structure as I wanted to have a vote to get see if people were filling to remove it with PHP 8 or leave it longer in the Engine. However looking at how some people voted against the deprecation notice but for the removal the only meaningfull conclusion I can come up with is that the change of the default value is the issue.
> I mean I don't see how we are in unchartered territory, the vote passed, >> sure >> with not a huge supra majority but it still passed. >> > > We're in unchartered territory not from a process perspective, but in > terms of the number of core devs who think it's a really bad idea and the > fact we're rediculously close to the minimum threshold - for something that > should really happen with consensus. >
I can see this but is it really unheard of?
> Moreover going about how Twitter [2] reacted (which isn't necessarely a >> good >> metric) it seems a *vast* majority is in favor of this change. >> > > It is, indeed, not a very good or even meaningful metric at all. The > folks which are likely to care about this are almost definitely severely > under-represented both here and on the dev cycles on Twitter. >
This may well be true but by the same argument I can say that a lot of people are for this even tho they didn't express this as much as those against it.
> I can consider it but I am really not keen on it. >> > > I'd sincrerely appreciate it if you did. I'm not fond of fighting > windmills, even less so nowadays than in the past - but I really think > we're making a painful mistake for virtually no gain, and I'm pretty sure > I'm not alone in thinking that. Ultimately, nothing in the RFC is new > compared to what we knew back in 1998 when we decided to have short open > tags. There are no new developments that make it more relevant today than > it was back then - if anything, XML is a lot less important today than it > was back then (when it was all the rage). And unlike 1998, the cost > assocaited with deprecating it now is tremendous. So even if we can argue > whether we took the right decision 20 years ago - there's really no new > grounds to reopen that decision today. >
The problem is if we don't address it now it will be even more complicated when PHP 9 rolls around and then again. I still believe these short tags are a legacy oddity that should be removed. Because what prevent me from then re-openning the vote again if the vote
>> then fails? >> > > Nothing really, other than common courtesy. > I was even hoping that the RFC will be withdrawn given the number of nays > from core devs, but that's of course something that is up to you. >
In all honesty I didn't check who votes for what as IMHO everybody is entitled to their opinion.
> What happens if the deprecation vote fails but not the removal? >> > Would this imply changing how it is deprecated which is literally the >> topic of the >> other thread without any more voting which I'm totally open to how it is >> changed? >> >> I don't even mind still having a compile error in PHP 8 when it sees the >> token >> as I said before I don't really care that much about the timeline. >> > > I think the real question this RFC raises is whether we want to deprecate > There are several valid options: > - Do nothing (which probably gets my vote) > - Deprecate it in 7.4, and remove it in 8.0 > - Deprecate it in 7.4, and error out over it in 8.0 > - Deprecate it in 8.0, and figure out what we want to do with it as we > gear towards 9.0 (which would give us time to gauge the feedback before > taking decisions - something that won't really be possible with 7.4/8.0 > given the short timelines) > > What I don't really think is a possibility is removing it (one way or > another) in 8.0 without first deprecating it in 7.4 (which again, is what I > found a bit confusing about the vote options). > > I would consider restructuring the questions in a different way than they > currently are and restart the vote: > > Primary Question - Deprecate short open tags yes/no (requires 2/3 > majority) > Secondary Question - which version 7.4/8.0 (simple majority) > Secondary Question - what to do when we remove it - silent removal, error, > something else? (simple majority) > > Thanks, > > Zeev >
The problem I have with putting this again to a vote is that it feels revote until the outcomes is convenient to me. And going with this logic I feel I could say let's redo a vote to deprecate the var keywword as the last vote was 3 years ago and maybe opinions have changed. It just end in more resentment IMHO. On Sun, 28 Apr 2019 at 21:46, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> Hi! > > On 4/28/19 4:52 AM, Benjamin Morel wrote: > >> I don't even mind still having a compile error in PHP 8 when it sees the > > token > > I thought one of the arguments for the whole enterprise was to enable > obviously won't work with this solution. And the "parser simplification" > claimed by RFC would also not happen, I imagine, since there's still two > separate tokens. So we are already out of at least half the reasons > original RFC has claimed... > -- > Stas Malyshev > smalyshev@gmail.com
Oh good to have you onboard for the initial RFC and remove it with PHP 8. I suppose the discussion is closed then in this case. :) Best regards George P. Banyard
  105501
April 29, 2019 08:01 zeev@php.net (Zeev Suraski)
On Sun, Apr 28, 2019 at 11:32 PM G. P. B. banyard@gmail.com> wrote:

> On Sun, 28 Apr 2019 at 14:36, Zeev Suraski <zeev@php.net> wrote: > >> As I said numerous times in the past, I'm a firm believer that >>>> controversial RFCs (ones that generate a lot of votes with a substantial >>>> number of opposers) should not pass. I think this is important when >>>> adding >>>> features - but it's actually a lot more important with deprecations. >>>> When >>>> there's substantial doubt whether a deprecation should go through or >>>> not, >>>> there should be no doubt at all - it shouldn't. This is one of the >>>> clearest cases if not the clearest one we've had to date. >>>> >>> >>> This IMHO applies to the deprecation vote which includes the default >>> change >>> >> >> From my POV it applies to all deprecations, although obviously taking out >> something that's been a basic building block for the last 20+ years is >> probably more of an issue than some 3rd party utility function. >> > > I think this just boils down to what is an acceptable majority, if 2/3 is > not enough then 3/4 > but this is another debate altogether. >
I've argued in the past that it would make sense to require a 9/10 majority for RFCs. Very few RFCs that passed - only cleared a 2/3 majority. Usually (in the vast majority of cases), it either clears a nearly unanimous vote - or it doesn't even come close to 2/3. RFCs that have a high number of votes (i.e., that people feel strongly about), and barely pass the 2/3 mark - are controversial and saw division. Yes, it means that out of the (almost random) group of people who are currently enabled to vote by our (flawed) voting system - there are 2x more people that want the RFC to pass vs. not, but at the same time, it also means that there's a great number of folks who think that it's a Really Bad Idea. This is even stronger with deprecations, where the biggest downside is compatibility breakage. Unlike new features, where you simply have to illustrate that the feature is a good idea - here, you don't only have to demonstrate that the feature you propose to deprecate is a bad idea - but rather, that it's so bad - that we're better off removing it and inducing compatibility breakage on our huge, several million strong userbase. If a very substantial number of folks thinks otherwise, it should make others pause - even if they dislike this feature and think it's bad, and consider whether it's really so horrid that it must be removed. Unfortunately, this line of thought doesn't appear to be happening - and it seems that many vote in favor of deprecation based on whether or not they like the feature. It's absolutely fine to dislike short tags. It's absolutely fine to believe it shouldn't have been introduced. But the gap between that, and thinking it's fine to remove it - is very, very big. This was indeed the intention of the voting structure as I wanted to have a
> vote to get see > if people were filling to remove it with PHP 8 or leave it longer in the > Engine. > > However looking at how some people voted against the deprecation notice > but for the removal > the only meaningfull conclusion I can come up with is that the change of > the default value is > the issue. >
It's very difficult to deduce what people were thinking because the questions were not properly structured. Some people probably only voted on one vote and not the other, thinking the other is irrelevant. It's fairly difficult to guess how it influenced the final tally, all the more reason to properly restructure the vote and restart it.
> >> I mean I don't see how we are in unchartered territory, the vote passed, >>> sure >>> with not a huge supra majority but it still passed. >>> >> >> We're in unchartered territory not from a process perspective, but in >> terms of the number of core devs who think it's a really bad idea and the >> fact we're rediculously close to the minimum threshold - for something that >> should really happen with consensus. >> > > I can see this but is it really unheard of? >
It's not unheard of, but it's also extremely uncommon. And in my opinion, should be avoided - especially in cases like this - where the value associated with the RFC isn't overwhelming. In the grand scheme of things, removing short tags isn't going to move the needle for the popularity of PHP, definitely not in a positive direction anyway. It has mostly the potential to make certain folks feel better about the syntactical purity of the language - while at the same time making the upgrade process more difficult - in a world where one of our biggest challenges is that people don't upgrade frequently enough.
> Because what prevent me from then re-openning the vote again if the vote >>> then fails? >>> >> >> Nothing really, other than common courtesy. >> I was even hoping that the RFC will be withdrawn given the number of nays >> from core devs, but that's of course something that is up to you. >> > > In all honesty I didn't check who votes for what as IMHO everybody is > entitled > to their opinion. >
Of course everyone is entitled to an opinion, but not everyone is entitled to a vote. As I've said numerous times over the years, our voting system is flawed and provides voting privileges to folks who are not supposed to have voting privleges per the Voting RFC, simply because it was the simplest way to implement it at the time. It created a situation that has no parallels in the Open Source world, at least none I'm aware of. Open Source projects (non-commercial ones at least) tend to always be based on meritocracy. PHP is pretty much the only high profile project where someone who spend years of their time working on creating the project, has the same weight as someone who submitted a couple of patches or even didn't submit any patches at all. And no, it was never intentional - it's a flaw of the voting system that is only getting bigger and bigger as years go by - where the number of core devs stays roughly the same, but the number of folks with voting access grows larger and larger. And no, it's not that I think we 'saw the light' that all other OS projects don't see. Fixing it is simply a very challenging task that nobody has been up for thus far.
> The problem I have with putting this again to a vote is that it feels > revote until the > outcomes is convenient to me. And going with this logic I feel I could say > let's > redo a vote to deprecate the var keywword as the last vote was 3 years ago > and maybe opinions have changed. It just end in more resentment IMHO. >
Ther'e s fundametal difference between votes that were already implemented and went out, and something where the vote just ended a couple of days ago. Even more so given the fact that there were issues with the way the voting options were laid out that made them inconsistent with the Voting RFC and our rules, and might have influenced how people voted (in both directions). That alone should be sufficient grounds to redo the vote and do it properly. Zeev
  105504
April 29, 2019 09:32 lester@lsces.co.uk (Lester Caine)
On 29/04/2019 09:01, Zeev Suraski wrote:
> It's absolutely fine to dislike short tags. It's absolutely fine to > believe it shouldn't have been introduced. But the gap between that, and > thinking it's fine to remove it - is very, very big.
And how long after it's removed will 'https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
  105519
April 30, 2019 17:14 derick@php.net (Derick Rethans)
On Mon, 29 Apr 2019, Zeev Suraski wrote:

> On Sun, Apr 28, 2019 at 11:32 PM G. P. B. banyard@gmail.com> wrot= e:
>=20 > > I think this just boils down to what is an acceptable majority, if=20 > > 2/3 is not enough then 3/4 but this is another debate altogether. > > >=20 > I've argued in the past that it would make sense to require a 9/10 majori= ty
> for RFCs. Very few RFCs that passed - only cleared a 2/3 majority. > Usually (in the vast majority of cases), it either clears a nearly > unanimous vote - or it doesn't even come close to 2/3. >=20 > RFCs that have a high number of votes (i.e., that people feel strongly > about), and barely pass the 2/3 mark - are controversial and saw division= =2E
> Yes, it means that out of the (almost random) group of people who are > currently enabled to vote by our (flawed) voting system
If you think it's flawed, you know that the RFC process is there for=20 anybody to change it. Joe already managed twice towards what you=20 suggested in your stalled RFC: - https://wiki.php.net/rfc/abolish-short-votes - https://wiki.php.net/rfc/abolish-narrow-margins (btw, you voted=20 against this one to raise the barrier from 50%+1 to =E2=85=94rds).
> It's absolutely fine to dislike short tags. It's absolutely fine to=20 > believe it shouldn't have been introduced. But the gap between that,=20 > and thinking it's fine to remove it - is very, very big.
But the fact is that the RFC passed. And retroactively changing rules=20 because somebody don't agree with a decision is making a farce out of=20 the process. So what's next? From what I understood, Nikita and George have spoken to=20 take Nikita's implementation proposals forwards. I'm pretty sure that=20 this will result in another RFC on which we then can vote. cheers, Derick --=20 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
  105523
April 30, 2019 18:25 zeev@php.net (Zeev Suraski)
On Tue, Apr 30, 2019 at 8:14 PM Derick Rethans <derick@php.net> wrote:

> On Mon, 29 Apr 2019, Zeev Suraski wrote: > > > On Sun, Apr 28, 2019 at 11:32 PM G. P. B. banyard@gmail.com> > wrote: > > > > > I think this just boils down to what is an acceptable majority, if > > > 2/3 is not enough then 3/4 but this is another debate altogether. > > > > > > > I've argued in the past that it would make sense to require a 9/10 > majority > > for RFCs. Very few RFCs that passed - only cleared a 2/3 majority. > > Usually (in the vast majority of cases), it either clears a nearly > > unanimous vote - or it doesn't even come close to 2/3. > > > > RFCs that have a high number of votes (i.e., that people feel strongly > > about), and barely pass the 2/3 mark - are controversial and saw > division. > > Yes, it means that out of the (almost random) group of people who are > > currently enabled to vote by our (flawed) voting system > > If you think it's flawed
It's not that I think it's flawed - I know it's flawed. It doesn't implement what was agreed upon when the Voting RFC was enacted.
> , you know that the RFC process is there for > anybody to change it. Joe already managed twice towards what you > suggested in your stalled RFC: > > - https://wiki.php.net/rfc/abolish-short-votes > - https://wiki.php.net/rfc/abolish-narrow-margins (btw, you voted > against this one to raise the barrier from 50%+1 to ⅔rds). >
I'm well aware of it. In doing that, I think we greatly complicated the prospects of fixing the voting eligibility - which is an infinitely hotter potato to handle. Both 'abolish' RFCs enjoyed popular support and had very little touchy subjects - unlike the topic of who gets to vote, or the prospect of moving to a consensus-based system.
> It's absolutely fine to dislike short tags. It's absolutely fine to > > believe it shouldn't have been introduced. But the gap between that, > > and thinking it's fine to remove it - is very, very big. > > But the fact is that the RFC passed. And retroactively changing rules > because somebody don't agree with a decision is making a farce out of > the process. >
I've detailed the issues with the RFC in my other reply. I'm well aware that I'm spending quite a bit of 'credit capital' by weighing in on this, and I'm enjoying it roughly as one would enjoy having their tooth pulled out without anesthesia (which still pales in comparison to what it would take to fix our voting process, which will probably be akin to having an entire set of teeth pull out in the same way). The reason I'm still doing it is that it's clear this RFC was flawed in its voting options, its substance, and the level of discussion that surrounded it (the last one is my opinion, the first two are facts) - and it will have HUGE implications on hundreds of thousands if not millions of users. So as I said when I first engaged this thread - as much as I'm 'enjoying' this, I prefer to take the personal hit and do whatever I can to prevent our users from taking the hit. If we are to inflict this hit on our users - we need to have each and every t crossed and i dotted. Zeev
  105524
April 30, 2019 18:38 mo.mu.wss@gmail.com ("M. W. Moe")
Hello,

a bit of fuzz; no need having a dramatic posture either; php RFC system
needs to be matured; the same way
than c++ fellowship (I don't say it was without dramas over the years); in
my opinion there are two many of them
opened at the same time; some targets strictly the userspace; some language
features and finally other regards
the zend engine (absolute on purpose); maybe they should not be discussed
on the same list.

tschüss!

On Tue, Apr 30, 2019 at 11:25 AM Zeev Suraski <zeev@php.net> wrote:

> On Tue, Apr 30, 2019 at 8:14 PM Derick Rethans <derick@php.net> wrote: > > > On Mon, 29 Apr 2019, Zeev Suraski wrote: > > > > > On Sun, Apr 28, 2019 at 11:32 PM G. P. B. banyard@gmail.com> > > wrote: > > > > > > > I think this just boils down to what is an acceptable majority, if > > > > 2/3 is not enough then 3/4 but this is another debate altogether. > > > > > > > > > > I've argued in the past that it would make sense to require a 9/10 > > majority > > > for RFCs. Very few RFCs that passed - only cleared a 2/3 majority. > > > Usually (in the vast majority of cases), it either clears a nearly > > > unanimous vote - or it doesn't even come close to 2/3. > > > > > > RFCs that have a high number of votes (i.e., that people feel strongly > > > about), and barely pass the 2/3 mark - are controversial and saw > > division. > > > Yes, it means that out of the (almost random) group of people who are > > > currently enabled to vote by our (flawed) voting system > > > > If you think it's flawed > > > It's not that I think it's flawed - I know it's flawed. It doesn't > implement what was agreed upon when the Voting RFC was enacted. > > > > , you know that the RFC process is there for > > anybody to change it. Joe already managed twice towards what you > > suggested in your stalled RFC: > > > > - https://wiki.php.net/rfc/abolish-short-votes > > - https://wiki.php.net/rfc/abolish-narrow-margins (btw, you voted > > against this one to raise the barrier from 50%+1 to ⅔rds). > > > > I'm well aware of it. In doing that, I think we greatly complicated the > prospects of fixing the voting eligibility - which is an infinitely hotter > potato to handle. Both 'abolish' RFCs enjoyed popular support and had very > little touchy subjects - unlike the topic of who gets to vote, or the > prospect of moving to a consensus-based system. > > > It's absolutely fine to dislike short tags. It's absolutely fine to > > > believe it shouldn't have been introduced. But the gap between that, > > > and thinking it's fine to remove it - is very, very big. > > > > But the fact is that the RFC passed. And retroactively changing rules > > because somebody don't agree with a decision is making a farce out of > > the process. > > > > I've detailed the issues with the RFC in my other reply. > > I'm well aware that I'm spending quite a bit of 'credit capital' by > weighing in on this, and I'm enjoying it roughly as one would enjoy having > their tooth pulled out without anesthesia (which still pales in comparison > to what it would take to fix our voting process, which will probably be > akin to having an entire set of teeth pull out in the same way). The > reason I'm still doing it is that it's clear this RFC was flawed in its > voting options, its substance, and the level of discussion that surrounded > it (the last one is my opinion, the first two are facts) - and it will have > HUGE implications on hundreds of thousands if not millions of users. So as > I said when I first engaged this thread - as much as I'm 'enjoying' this, I > prefer to take the personal hit and do whatever I can to prevent our users > from taking the hit. > > If we are to inflict this hit on our users - we need to have each and every > t crossed and i dotted. > > Zeev >
  105528
April 30, 2019 20:18 peterkokot@gmail.com (Peter Kokot)
Hello,

On Tue, 30 Apr 2019 at 20:25, Zeev Suraski <zeev@php.net> wrote:
> > On Tue, Apr 30, 2019 at 8:14 PM Derick Rethans <derick@php.net> wrote: > > > On Mon, 29 Apr 2019, Zeev Suraski wrote: > > > > > On Sun, Apr 28, 2019 at 11:32 PM G. P. B. banyard@gmail.com> > > wrote: > > > > > > > I think this just boils down to what is an acceptable majority, if > > > > 2/3 is not enough then 3/4 but this is another debate altogether. > > > > > > > > > > I've argued in the past that it would make sense to require a 9/10 > > majority > > > for RFCs. Very few RFCs that passed - only cleared a 2/3 majority. > > > Usually (in the vast majority of cases), it either clears a nearly > > > unanimous vote - or it doesn't even come close to 2/3. > > > > > > RFCs that have a high number of votes (i.e., that people feel strongly > > > about), and barely pass the 2/3 mark - are controversial and saw > > division. > > > Yes, it means that out of the (almost random) group of people who are > > > currently enabled to vote by our (flawed) voting system > > > > If you think it's flawed > > > It's not that I think it's flawed - I know it's flawed. It doesn't > implement what was agreed upon when the Voting RFC was enacted. > > > > , you know that the RFC process is there for > > anybody to change it. Joe already managed twice towards what you > > suggested in your stalled RFC: > > > > - https://wiki.php.net/rfc/abolish-short-votes > > - https://wiki.php.net/rfc/abolish-narrow-margins (btw, you voted > > against this one to raise the barrier from 50%+1 to ⅔rds). > > > > I'm well aware of it. In doing that, I think we greatly complicated the > prospects of fixing the voting eligibility - which is an infinitely hotter > potato to handle. Both 'abolish' RFCs enjoyed popular support and had very > little touchy subjects - unlike the topic of who gets to vote, or the > prospect of moving to a consensus-based system. > > > It's absolutely fine to dislike short tags. It's absolutely fine to > > > believe it shouldn't have been introduced. But the gap between that, > > > and thinking it's fine to remove it - is very, very big. > > > > But the fact is that the RFC passed. And retroactively changing rules > > because somebody don't agree with a decision is making a farce out of > > the process. > > > > I've detailed the issues with the RFC in my other reply. > > I'm well aware that I'm spending quite a bit of 'credit capital' by > weighing in on this, and I'm enjoying it roughly as one would enjoy having > their tooth pulled out without anesthesia (which still pales in comparison > to what it would take to fix our voting process, which will probably be > akin to having an entire set of teeth pull out in the same way). The > reason I'm still doing it is that it's clear this RFC was flawed in its > voting options, its substance, and the level of discussion that surrounded > it (the last one is my opinion, the first two are facts) - and it will have > HUGE implications on hundreds of thousands if not millions of users. So as > I said when I first engaged this thread - as much as I'm 'enjoying' this, I > prefer to take the personal hit and do whatever I can to prevent our users > from taking the hit. > > If we are to inflict this hit on our users - we need to have each and every > t crossed and i dotted. > > Zeev
Some languages out there have an idiom for this kind of a situation: This thread right here is making an elephant out of the fly. Meaning something is exaggerating or make something more serious than it actually is. Worth noting another inconsistency here that we've missed. PHP 7.4 has introduced many BC breaks actually already. Without this level of problems: - *nix build system now uses pkg-config and basically has changed so many configure options that building this is a completely new chapter on its own - removed wddx - removed interbase - entire Backward Incompatible Changes section in the UPGRADING file: https://github.com/php/php-src/blob/PHP-7.4/UPGRADING The deprecation in PHP 7.4 (or even if there wouldn't be any deprecation here at all) and removal of some short tags in PHP 8 is the least of users problems I think. If the next RFC on this topic would happen (in my opinion it is pointless) it should make only something more clear. That is how to remove them. In PHP 8.0 directly as is now the result of this RFC or in PHP 9.0 removal and in PHP 8.0 using a compilation error. Anything in between is a more or less a revert of the original RFC which would then come to a question of why making these RFCs at all and why voting even matters. Without these kind of "hacks" PHP wouldn't even move forward anymore. Contributing to it would be in most cases only maintenance, fixing bugs and compatibility with platforms out there. So nothing exciting anymore like making it more syntactically correct, more logical etc. (these are very important changes also beside new functionality and extensions). -- Peter Kokot
  105535
April 30, 2019 22:56 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> Worth noting another inconsistency here that we've missed. PHP 7.4 has > introduced many BC breaks actually already. Without this level of > problems:
Exactly, without. There's a difference between removing an unmaintained extension which is barely used and setting people up for displaying their sources if they use slightly outdated libraries. And there's a difference between explicitly making a decision and not even bothering to discuss this mammoth of a BC break until the vote is finished. So to me it's more like "elephant in the room" scenario - we've got a process failure here. We are on the course to correct it, but it's a failure nevertheless.
> The deprecation in PHP 7.4 (or even if there wouldn't be any > deprecation here at all) and removal of some short tags in PHP 8 is > the least of users problems I think.
You mean wddx removal is much bigger problem for users than the potential for their code to be sent out instead of executed? If so, we must be living in very different words, because for me the former is a blip on the margin of the radar and the latter is a "world on fire, do not upgrade under any circumstances" scenario. I could easily ignore the former and I wouldn't dare to upgrade any production for the latter without long process of verification that would 100% ensure there's no bad tags hiding in any code, any dependency, any library, etc. Maybe it's what the RFC authors want, but it's certainly a giant difference in BC impact.
> Without these kind of "hacks" PHP wouldn't even move forward anymore. > Contributing to it would be in most cases only maintenance, fixing > bugs and compatibility with platforms out there. So nothing exciting
There's a lot to do in PHP without breaking things. How much time you've got? -- Stas Malyshev smalyshev@gmail.com
  105537
May 1, 2019 00:19 peterkokot@gmail.com (Peter Kokot)
On Wed, 1 May 2019 at 00:56, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> > Hi! > > > Worth noting another inconsistency here that we've missed. PHP 7.4 has > > introduced many BC breaks actually already. Without this level of > > problems: > > Exactly, without. There's a difference between removing an unmaintained > extension which is barely used and setting people up for displaying > their sources if they use slightly outdated libraries. And there's a > difference between explicitly making a decision and not even bothering > to discuss this mammoth of a BC break until the vote is finished. So to > me it's more like "elephant in the room" scenario - we've got a process > failure here. We are on the course to correct it, but it's a failure > nevertheless.
It is a BC break nevertheless no matter how much time it takes to change the code. The level of the impact cannot be measured like this. Every app will have different things to fix. So saying that this particular change will break the internet is not realistic without any numbers. If PHP is on a course to fix the BC break strategy then good (for example, BC breaks allowed in major releases, minor releases including only new features etc). Upgrading PHP version would be then a breeze probably but very complex to maintain the code in the repo (at least according to the release cycles of 5+ years to get to a major version). However, I'm not sure I'm seeing such direction or anyone expressing it to do this at least according to many here and even this discussion. Because, from what I think here more is that we're discussing how to keep the short tags forever and how to remove them as soon as possible. There is a difference in what people want here. And majority of those not in favour of the removal in PHP 8, want them to have forever and basically want to change the issue of removing the tags in the first place. I haven't seen any step forward from this point yet and what kind of a different removal strategy (compared to Nikita's suggestion) would work.
> > The deprecation in PHP 7.4 (or even if there wouldn't be any > > deprecation here at all) and removal of some short tags in PHP 8 is > > the least of users problems I think. > > You mean wddx removal is much bigger problem for users than the > potential for their code to be sent out instead of executed? If so, we > must be living in very different words, because for me the former is a > blip on the margin of the radar and the latter is a "world on fire, do > not upgrade under any circumstances" scenario. I could easily ignore the > former and I wouldn't dare to upgrade any production for the latter > without long process of verification that would 100% ensure there's no > bad tags hiding in any code, any dependency, any library, etc. Maybe > it's what the RFC authors want, but it's certainly a giant difference in > BC impact.
I haven't seen code with short tags for such a long time now that this is for me a problem on a scale of a fly. Because we've simply upgraded all very very long time ago or in other words even never thought of writing something in these tags anymore. Well, obviously this might be for someone else a problem on a scale of an elephant, that I don't know and probably won't understand fully. But, also at least now this discussion and also RFC brought this thing out - short open tags shouldn't be used anymore in any case. :) Because obviously a very large number of people would like to have more clear definition of what is opening PHP tag. -- Peter Kokot
  105538
May 1, 2019 02:22 markyr@gmail.com (Mark Randall)
On 01/05/2019 01:19, Peter Kokot wrote:
> I haven't seen code with short tags for such a long time now that this > is for me a problem on a scale of a fly. Because we've simply upgraded > all very very long time ago or in other words even never thought of > writing something in these tags anymore.
I think it's important to remember that for every piece of actual code that's seen in the wild on the internet, there's likely a couple of orders of magnitude more that never leaves the proprietary servers / repositories of individual companies -- Code that has been written over a great many years that could always rely on short open tags being there because it's company code on company servers running php.inis configured by company staff. The code exposure is secondary IMO. I mean, it's certainly bad, but developers will be faced with a much more catastrophic issue to contend with, and that's the somewhat terrifying issue of logical control operations silently ceasing to exist. Super Secret: If people are so adamant about getting rid of it (as opposed to just making it always available) then I think Nikita needs to bring forward his proposals as an RFC with all due haste, as it's quite clear the current plan cannot go forward as-is. -- Mark Randall
  105540
May 1, 2019 07:42 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> Every app will have different things to fix. So saying that this > particular change will break the internet is not realistic without any > numbers. If PHP is on a course to fix the BC break strategy then good
I am not saying it will break the internet. Nobody does. What I am saying it creates a huge and serious risk (both operational and security) for people upgrading, and I am not sure why it is being dismissed roughly as "well, BC happens, what you gonna do..." In my opinion, it's not a kind of issue one should be dismissing. It's not a regular low-grade BC break, it's a serious and dangerous one. Probably one of the most dangerous - in its current state, as voted - among all present in the release.
> even this discussion. Because, from what I think here more is that > we're discussing how to keep the short tags forever and how to remove > them as soon as possible. There is a difference in what people want
I don't think dealing in absolutes here is helpful. There are more options than "ASAP" and "never". And I feel that the RFC as-is have not considered them thoroughly enough - otherwise I can not see how the issue of spilling out the source has not been handled.
> removing the tags in the first place. I haven't seen any step forward > from this point yet and what kind of a different removal strategy > (compared to Nikita's suggestion) would work.
Whatever removal strategy there is, it should not be "let's switch the default in 7.4, remove the whole token completely in 8.0 and let people that have > I haven't seen code with short tags for such a long time now that this > is for me a problem on a scale of a fly. Because we've simply upgraded
You must realize you haven't seen 99.999% of existing PHP code, and that's probably if you look at a lot of code? Massive amounts of code are not public. Massive amounts of code are using old library versions and old dependencies, a lot of them not easily upgradable to latest versions because the surrounding code is old too and newest versions break it. The fact that you personally haven't seen such code and it's not a problem for *you* doesn't mean a lot if you purport to take responsibility over the needs of millions of PHP users. Voting on RFC should not be an expression of a personal opinion and only it, if it is we have a grotesque situation where personal whims of barely 50 random people decide things for millions. This can only work if each of these people realizes the responsibility inherent in the decisions being taken and considers the impact that their vote would have not only for their personal needs, but for other users too.
> know and probably won't understand fully. But, also at least now this > discussion and also RFC brought this thing out - short open tags > shouldn't be used anymore in any case. :) Because obviously a very
There's a very big distance from recommending not using short tags to removing short tags from the parser. We've just voted for covering this distance in two releases. I think this would be a costly mistake. There are ways of doing it properly - Nikita's proposal could be one of them. -- Stas Malyshev smalyshev@gmail.com
  105558
May 2, 2019 11:23 pierre.php@gmail.com (Pierre Joye)
Hi,

On Wed, May 1, 2019, 2:42 PM Stanislav Malyshev <smalyshev@gmail.com> wrote:

> Hi! > > > Every app will have different things to fix. So saying that this > > particular change will break the internet is not realistic without any > > numbers. If PHP is on a course to fix the BC break strategy then good > > I am not saying it will break the internet. Nobody does. What I am > saying it creates a huge and serious risk (both operational and > security) for people upgrading, and I am not sure why it is being > dismissed roughly as "well, BC happens, what you gonna do..." In my > opinion, it's not a kind of issue one should be dismissing. It's not a > regular low-grade BC break, it's a serious and dangerous one. Probably > one of the most dangerous - in its current state, as voted - among all > present in the release. >
Btw, the core can veto a rfc if it actually creates big troubles, just to end a circular discussion. I am not asking to do it, but this is an option if really all core developers consider it very harmful. best, Pierre
>
  105542
May 1, 2019 09:23 zeev@php.net (Zeev Suraski)
On Wed, May 1, 2019 at 3:19 AM Peter Kokot <peterkokot@gmail.com> wrote:

> On Wed, 1 May 2019 at 00:56, Stanislav Malyshev <smalyshev@gmail.com> > wrote: > > > > Hi! > > > > > Worth noting another inconsistency here that we've missed. PHP 7.4 has > > > introduced many BC breaks actually already. Without this level of > > > problems: > > > > Exactly, without. There's a difference between removing an unmaintained > > extension which is barely used and setting people up for displaying > > their sources if they use slightly outdated libraries. And there's a > > difference between explicitly making a decision and not even bothering > > to discuss this mammoth of a BC break until the vote is finished. So to > > me it's more like "elephant in the room" scenario - we've got a process > > failure here. We are on the course to correct it, but it's a failure > > nevertheless. > > It is a BC break nevertheless no matter how much time it takes to > change the code. The level of the impact cannot be measured like this. >
Of course it can be. Scratch that - that's not one way to measure it, it's the only sensible way to measure it. The only way to look at this is a cost/benefit balance, and here, the cost is considerably high, and the gain is virtually non-existent. All the points the RFC mentions were known and factored in back in 1998, virtually all of them are either mild or factually wrong - such as the simplication of the parser (the parser is 100.000% oblivious to whether short tags are enabled or not, and they're implemented in roughly 10 lines of code that haven't changed for probably 15-20 years in the scanner). For mostly everything else deprecated in 7.4 and 7.x in general - the cost is typically very small - and often the gain is a lot more substantial. In other cases, the reason of the deprecation is simply coming to terms with reality - e.g. that a given extension isn't being actively maintained so we can no longer support it. There's no comparison between deprecating a basic building block that's been with us since 1998 - that will be all over the place in code that uses it (and there's plenty of that out there), with the deprecation or slight mods that will be affecting a tiny fragment of the userbase.
> I haven't seen code with short tags for such a long time now that this > is for me a problem on a scale of a fly.
This is *precisely* *not* the kind of thinking we should have here, and what I was alluding to when I spoke about responsibility. The fact you haven't seen code with short tags for a long time, means exactly that - that *you* haven't seen code with short tags for a long time. We can also build upon that, as well as feedback from others here and some indicators and trends in PHP development - and extrapolate that you're not an outlier here, and in fact, most folks who are at the top 10-20% - at least - haven't been using short tags for a very long time, if ever. I already said that I'm deep in that group as well. However, that's just one part of the PHP world. And on internals, we're supposed to care about the entire PHP world, including parts that are severly underrepresented here but nonetheless exist and are very large. There's TONS of PHP development going on behind closed doors, by developers who probably couldn't care less about PSR's, code beauty and even portability - given they're writing stuff for internal use. For others - they may care more, but have to maintain other people's code that's been working for ages - and they only have to do the minimal amount of work to keep it working as new versions are installed. As a project, we care *greatly *about people upgrading to the latest version - primarily for security considerations. The top reasons to upgrade, in my experience, have been (a) performance, and (b) security - with features coming at a distant third. That is especially true for legacy apps with little active development. Every BC break we add without an excellent reason, means that needlessly - fewer people will be upgrading, and those who would upgrade would do so on a longer time scale. Because we've simply upgraded
> all very very long time ago or in other words even never thought of > writing something in these tags anymore. Well, obviously this might be > for someone else a problem on a scale of an elephant, that I don't > know and probably won't understand fully. But, also at least now this > discussion and also RFC brought this thing out - short open tags > shouldn't be used anymore in any case. :) Because obviously a very > large number of people would like to have more clear definition of > what is opening PHP tag. > > To be honest, I don't think it's something at the scale of an elephant for
the vast majority of folks. But I think that may be cow-sized for many. The other side of the equation is that the benefit of removing it - is barely even a fly. This deprecation brings virtually no value. The cost/benefit balance weighs extremely against it. But you have to be thinking about the folks that aren't here on internals or in the top tier of PHP development in order to reach that conclusion. Zeev
  105574
May 2, 2019 22:21 george.banyard@gmail.com ("G. P. B.")
Evening internals,

I am not going to go into the details of every email which got sent in the
past two days as I am busy with Exam revision.

Main take away that I got from the previous emails:

1. No discussion:
It is indeed true that there hasn't been a lot (to not say none) of
discussion after the announcement but I hadn't gotten any reply after I
replied to the people who commented on it so, in my mind if there is no
more discussion I don't see why I should have waited longer to bring the
RFC to a vote.

2. Voting structure:
If the voting structure was that confusion, sending a message to the ML
like Peter Cowburn (@salathe) did would have allowed me to stop the vote
fix the structure and bring it back to a vote.
Saying that it was confusion after the vote is ended is IMHO just a way to
not assume responsibility and get your way because the result doesn't
pleases you.

No I don't see the rationale that saying the removal vote isn't an
implementation detail because from my perspective it is.
Because if not wouldn't the secondary vote on the JIT [1] RFC also not be
an implementation detail in this case?

Even though you could say how it was presented it is not a secondary vote
but then you can also considered it as a primary vote, and having multiple
primary votes in an RFC is allowed per the Voting RFC [2].

And if even then this doesn't seem right just render void the secondary
vote, no need to render void the whole RFC as the primary vote does respect
the Voting RFC.


As to why these issues haven't been addressed during the standard RFC
process, I have a couple of theories but I don't think they are worth
putting on this list.

On this note, if I missed anything important please send it my way and I
will try to respond to it ASAP but it could well be another 2 days or more
before I respond.



Best regards

George P. Banyard
  105612
May 7, 2019 11:28 zeev@php.net (Zeev Suraski)
On Fri, May 3, 2019 at 1:21 AM G. P. B. banyard@gmail.com> wrote:

> Evening internals, > > I am not going to go into the details of every email which got sent in the > past two days as I am busy with Exam revision. >
I was also kind of busy, but more importantly I wanted to wait a bit before I reply - as my previous quick-turnaround reply was offensive to you.
> Main take away that I got from the previous emails: > > 1. No discussion: > It is indeed true that there hasn't been a lot (to not say none) of > discussion after the announcement but I hadn't gotten any reply after I > replied to the people who commented on it so, in my mind if there is no > more discussion I don't see why I should have waited longer to bring the > RFC to a vote. >
That's understandable, but I believe there's a different explanation here. I hope you won't find it too offensive - but in my mind, the RFC was so off the charts a 'no', that I didn't think it stood a chance, and did not bother participating in it. I know several others who feel exactly the same way. Most of the discussion revolved around how easy it would be to work around the BC break we'd be introducing, and almost none of it was about justifying the BC break in the first place. Elements which were obviously wrong in the RFC - such as some of the motivation ("Simplifying the parser" - simply wrong) as well as the implications (potential for wholesale disclosure of code) - weren't discussed even one bit.
> 2. Voting structure: > If the voting structure was that confusion, sending a message to the ML > like Peter Cowburn (@salathe) did would have allowed me to stop the vote > fix the structure and bring it back to a vote. >
Perhaps. But the voting results make it clear beyond a reasonable doubt that the voting options were not clear - as in fact, we were a couple of votes away from creating an impossible outcome (remove in 8.0 without first deprecating in 7.4). Like I said, while it's impossible to determine whether this would have materially affected the results or not - it's obvious that there was confusion because of the way the vote was laid out. Saying that it was confusion after the vote is ended is IMHO just a way to
> not assume responsibility and get your way because the result doesn't > pleases you. >
It goes far beyond displeasing me. I think Stas (Stanislav) summarized it in the best possible way in his replies. I've had my share of RFCs whose outcome displeased me - but never one that failed to clear the most basic requirements for a healthy process. I want to make it clear - this is not entirely or even primarily your fault. The issues with the voting options should have been brought up much earlier in the process, and it's shameful that the discussion on internals was clearly remarkably shallow before this went to a vote. Neither of these are your fault, but these are faults that need to be fixed.
> No I don't see the rationale that saying the removal vote isn't an > implementation detail because from my perspective it is. >
Something that will effect hundreds of thousands of developers is not an implementation detail.
> Because if not wouldn't the secondary vote on the JIT [1] RFC also not be > an implementation detail in this case? >
I admit you have a point. Strictly speaking, it should have been in two separate primary votes - where we first vote for the 8.0 question, and then (in a separate, followup RFC) vote for the whether to also include it in 7.4. However, there are several key differenating factors: 1. Unlike the short tags RFC, there was in-depth discussion around the JIT patch on internals - and in particular the merits as well as the disadvantages of including it as experimental in 7.4 was thoroughly discussed. At least to those who read the discussion - it was clear what the key question was and what the secondary question was, and the dependency between them (no way we're going to include it as experimental in 7.4 if we don't plan to roll it out in 8.0). 2. When you look at the voting results, it's clear that this understanding extended to virtually everyone who voted on the JIT RFC. The only two people who voted against inclusion in 8.0, also voted against inclusion in 7.4. Put another way, there's not a single person who voted for inclusion in 7.4 while voting against inclusion in 8.0. The dependecy was clear. 3. Unlike the voting question at hand (in the short tags RFC), the implications are far reaching (in fact, a lot farther reaching than anybody initially realized) - inclusion in 7.4 has virtually no implication on anybody that's not proactively trying to use it (which based on our experience with past experimental features, isn't a great deal of people at all). 4. The results of both questions in the JIT RFC were extremely clear cut. One at 96% in favor (clear consensus in favor), and the other 67% against (clearly very very far from consensus or even majority). Even if somebody was confused by the voting questions, it's unlikely to have made a difference one way or another. Not so with the short tags RFC, which either barely or narrowly cleared the mark(s). That said, if anybody believes that there was any confusion with the JIT RFC voting options, we can redo the votes on them (as two separate votes). Even though you could say how it was presented it is not a secondary vote
> but then you can also considered it as a primary vote, and having multiple > primary votes in an RFC is allowed per the Voting RFC [2]. >
There are two issues with this: 1. It was in fact presented as a secondary vote. 2. Placing these two primary votes in the same RFC doesn't go against our RFC rules, but it does go against our deprecation rules - where we always deprecate features before removing them. The right way to do the voting options on this RFC is actually dividing it to two separate votes - first, are we deprecating this feature? Secondly, if and only if we decided to deprecate it, do we remove it right away in 8.0, or keep it for now given the very short time between deprecation and removal. Also, the 2nd RFC should detail the right way of handling the removal (error instead of silently ignoring). And if even then this doesn't seem right just render void the secondary
> vote, no need to render void the whole RFC as the primary vote does respect > the Voting RFC. >
I disagree. This RFC as a whole is incompatible with the Voting RFC, and it's clear that people were confused with the voting options and the dependencies between them. It may have affected both the way people voted, and even whether or not certain people voted in the first place. The only way to fix it, is to redo the vote properly - ideally after we actually discuss the merits of going through this BC break in the first place. Zeev
  105682
May 11, 2019 18:56 peterkokot@gmail.com (Peter Kokot)
Not trying to rush anyone to something they have no energy working on
anymore here but what's the plan here then? And what plan is there
with these short tags on the long run?
  105786
May 24, 2019 16:52 peterkokot@gmail.com (Peter Kokot)
Hello,

On Sat, 11 May 2019 at 20:56, Peter Kokot <peterkokot@gmail.com> wrote:
> > Not trying to rush anyone to something they have no energy working on > anymore here but what's the plan here then? And what plan is there > with these short tags on the long run?
I'm just checking then why is this RFC in the pending implementation state if basically we're on a way to have the short opening tags in PHP for ever... Maybe we should then enable them by default to have the other way around situation of having both tags for few 10 years and then ditch the long one if it's not going to be deprecated in PHP 7.4 and decided what to do with them? https://wiki.php.net/rfc/deprecate_php_short_tags -- Peter Kokot
  105956
June 17, 2019 10:55 nikita.ppv@gmail.com (Nikita Popov)
On Fri, May 24, 2019 at 6:53 PM Peter Kokot <peterkokot@gmail.com> wrote:

> Hello, > > On Sat, 11 May 2019 at 20:56, Peter Kokot <peterkokot@gmail.com> wrote: > > > > Not trying to rush anyone to something they have no energy working on > > anymore here but what's the plan here then? And what plan is there > > with these short tags on the long run? > > I'm just checking then why is this RFC in the pending implementation > state if basically we're on a way to have the short opening tags in > PHP for ever... Maybe we should then enable them by default to have > the other way around situation of having both tags for few 10 years > and then ditch the long one if it's not going to be deprecated in PHP > 7.4 and decided what to do with them? > > https://wiki.php.net/rfc/deprecate_php_short_tags >
Girgias has put up a new implementation at https://github.com/php/php-src/pull/4263. If short_open_tag=On and
  106026
June 22, 2019 11:01 zeev@php.net (Zeev Suraski)
On Mon, Jun 17, 2019 at 1:55 PM Nikita Popov ppv@gmail.com> wrote:

> On Fri, May 24, 2019 at 6:53 PM Peter Kokot <peterkokot@gmail.com> wrote: > > > Hello, > > > > On Sat, 11 May 2019 at 20:56, Peter Kokot <peterkokot@gmail.com> wrote: > > > > > > Not trying to rush anyone to something they have no energy working on > > > anymore here but what's the plan here then? And what plan is there > > > with these short tags on the long run? > > > > I'm just checking then why is this RFC in the pending implementation > > state if basically we're on a way to have the short opening tags in > > PHP for ever... Maybe we should then enable them by default to have > > the other way around situation of having both tags for few 10 years > > and then ditch the long one if it's not going to be deprecated in PHP > > 7.4 and decided what to do with them? > > > > https://wiki.php.net/rfc/deprecate_php_short_tags > > > > Girgias has put up a new implementation at > https://github.com/php/php-src/pull/4263. > > If short_open_tag=On and thrown. short_open_tag=On remains the default, so there will be no > accidental code leakage due to changed defaults. If short_open_tag=Off, > then > I believe that addresses the implementation concerns and we can go ahead > with landing this RFC. >
Nikita, I wrote a fairly detailed response to why I believe we should re-do the RFC and vote, given multiple issues with the original one. While there was a response to it, I very much stand by what I said in it - namely, that the discussion was toe-deep in a way that is unbecoming for such a basic building block (as unpopular as it may be), that some of the motivations mentioned in the RFC were simply wrong (e.g. 'simplification of the parser') and that the voting options were confusing - which may have impacted the vote in certain ways. I see no way forward other than redoing it. This feature has been with us for over 20 years, we can spend a couple of more weeks deprecating it properly if we really need to (and perhaps consider the 'legacy' extension option - providing a win-win of sorts, where we can both move forward with 'cleanups' - but also provide a painless path forward for the ones affected). Zeev
  105503
April 29, 2019 08:17 nikita.ppv@gmail.com (Nikita Popov)
On Sun, Apr 28, 2019 at 10:02 AM Zeev Suraski <zeev@php.net> wrote:

> On Wed, Apr 24, 2019 at 9:08 PM Reinis Rozitis <r@roze.lv> wrote: > > > Also imo the reason why people write now (and not in the discussion > > phase) because for some time in the voting there wasn't the 2/3 majority > > for the 7.4 (so no sense to clutter the list) and now in the end only 1-2 > > votes make the difference. > > > > > At least for me, this definitely was the case. When I voted, it was > nowhere near clearing the 2/3 threshold. > > As I said numerous times in the past, I'm a firm believer that > controversial RFCs (ones that generate a lot of votes with a substantial > number of opposers) should not pass. I think this is important when adding > features - but it's actually a lot more important with deprecations. When > there's substantial doubt whether a deprecation should go through or not, > there should be no doubt at all - it shouldn't. This is one of the > clearest cases if not the clearest one we've had to date. >
Keep in mind that for example the FFI RFC passed with something like 60% majority, even lower than this RFC. I think you're cherry-picking a bit here, when it comes to what should and shouldn't pass ;) Process wise we're in a bit of an unchartered territory here, but I don't
> think we should let the headache involved with figuring out how to reverse > this decision force us to impose this on our users. It's better to go > through this unpleasantry now than deal with the backlash later. >
I think that process-wise (if we can't agree on landing some variation of this, as I've suggested in a separate thread) the right thing to do would be to draft a new RFC that overrules this one. It can lay out the new arguments that have come up in the meantime in an orderly manner and be voted separately. Nikita
  105506
April 29, 2019 12:29 zeev@php.net (Zeev Suraski)
On Mon, Apr 29, 2019 at 11:17 AM Nikita Popov ppv@gmail.com> wrote:

> > Keep in mind that for example the FFI RFC passed with something like 60% > majority, even lower than this RFC. I think you're cherry-picking a bit > here, when it comes to what should and shouldn't pass ;) >
You're right, but I think that's a price well worth paying (i.e., I'd be absolutely fine if the FFI RFC did not pass, as well as some other RFCs I was fond of, if it meant that controversial RFCs were a thing of the past - at least in terms of passing).
> Process wise we're in a bit of an unchartered territory here, but I don't >> think we should let the headache involved with figuring out how to reverse >> this decision force us to impose this on our users. It's better to go >> through this unpleasantry now than deal with the backlash later. >> > > I think that process-wise (if we can't agree on landing some variation of > this, as I've suggested in a separate thread) the right thing to do would > be to draft a new RFC that overrules this one. It can lay out the new > arguments that have come up in the meantime in an orderly manner and be > voted separately. >
If we go in this direction, though, then unless George agrees to withdraw this RFC and have it replaced by another - it means that the 'status quo' is that short tags are out, and there must be a 2/3 majority to undo that. Where we stand - I don't think it's a very likely scenario. It's clear there are many folks that want short tags gone - probably more so than there are those who think they should stay (and not necessarily because they love them). Zeev
  105507
April 29, 2019 14:18 Danack@basereality.com (Dan Ackroyd)
On Mon, 29 Apr 2019 at 13:29, Zeev Suraski <zeev@php.net> wrote:
> > If we go in this direction, though, then unless George agrees to withdraw >this RFC
Zeev, I do not think you behaviour is appropriate. It's not appropriate to put pressure on an RFC author to withdraw an RFC after it has been voted on. It's not appropriate to try to change the rules on voting after a vote has occurred. Please stop doing this.
> We're in unchartered territory not from a process perspective, but in terms > of the number of core devs
I don't believe that is true* (there appear to be core devs on both sides of the vote) but even if it was, this is not an internal engine matter, where the decision is going to cause a significant amount of work for people who work on PHP core. I strongly doubt this type of RFC is ever going to be reserved for core developers choice only. For the record I think the result of the vote is dumb, and I hope that the situation will be resolved before the 7.4 release. And I also agree that we should have clearer rules about who qualifies for a vote. But trying to subvert a vote after it has happened is not appropriate imo. Nikita Popov has already started a new thread in an attempt to make the situation be more acceptable. That is the correct way of resolving problems like this. Putting pressure on people to bend the rules is not. cheers Dan Ack * If you'd described it as release managers were all voting on one side, then it would be true.
  105510
April 29, 2019 14:26 zeev@php.net (Zeev Suraski)
On Mon, Apr 29, 2019 at 5:19 PM Dan Ackroyd <Danack@basereality.com> wrote:

> On Mon, 29 Apr 2019 at 13:29, Zeev Suraski <zeev@php.net> wrote: > > > > If we go in this direction, though, then unless George agrees to withdraw > >this RFC > > Zeev, > > I do not think you behaviour is appropriate. > > It's not appropriate to put pressure on an RFC author to withdraw an > RFC after it has been voted on. > > It's not appropriate to try to change the rules on voting after a vote > has occurred. >
No Dan. What's inappropriate is the wholesale compatibility break-fast that we're experiencing here, for virtually no reason, while exhibiting total disregard for the issues we're creating for folks out there. I do not feel comfortable having to ask George to withdraw or reopen his RFC, but I feel a lot less comfortable betraying the trust of millions of developers - so I'm doing it anyway, despite the unpleasantry involved.
> Please stop doing this. >
I will gladly do so, once the project starts behaving responsibly again. You may think I'm enjoying it, or otherwise taking it lightly - but trust me, there's nothing I hate doing more than quaralleing on things like that on internals. And yet, this must be done. Zeev
  105509
April 29, 2019 14:33 zeev@php.net (Zeev Suraski)
On Mon, Apr 29, 2019 at 5:26 PM Zeev Suraski <zeev@php.net> wrote:

> > ... wholesale compatibility break-fast ... > * break-fest
  105514
April 30, 2019 11:13 george.banyard@gmail.com ("G. P. B.")
On Mon, 29 Apr 2019 at 16:53, Zeev Suraski <zeev@php.net> wrote:

> On Mon, Apr 29, 2019 at 5:19 PM Dan Ackroyd <Danack@basereality.com> > wrote: > > Please stop doing this. > > I will gladly do so, once the project starts behaving responsibly again. >
Honnestly, this comment right here Zeev just makes me want to not compromise at all. I think you seriously lost any hope there was that I'm going to put back this to a vote. Why the hell should I start compromising with someone who thinks the project, and by extensions the contributors to the project small or large, don't behave responsibly?! You say that this deprecation is an insult to our legacy users but you just casually insult (at least in my mind) the people who make this project live on. Or are you just remicinent of ye olden days where core devs decided willy nilly what ever they want to do with the project? Because I though the whole idea behind the RFC process is to prevent this "closed club" of core dev who can decide whatever they want. Also you go on about how 2/3 majority is to small when you self used even lower margins to get RFCs accepted. From what I know nothing prevented you to asked a 90% acceptance rate on all the RFCs that you proposed/co-authored if you felt that strong about "consensus" as the Voting process, to my understanding, only asks for minimums. And if you think I'm being unreasonable here, well I'm not because my RFC passed fair and square while having a longer period then what was required at the time (which funnily enough you also love having small voting windows). And do you think it would have been resonable of me to come complaining about how my vote failed if there would have only been 66% in favor instead of the 2/3? You would have had no problem then to say that it failed no more discussion needed instead of draging this along for about a week after the vote ended. I was willing to compromise a lot but with all the respect I have for you Zeev, your sheer arogance just made any major compromise not a thing I want to pursue anymore. I'll accept amendments to how the deprecation is handled and implemented with any ideas that may arise on the nikic's thread on how to handle it. And if an RFC amendment is needed I will personaly only accept a vote on HOW this RFC is implemented and not a vote on IF this should be done. And if you are not happy with this, blame yourself. Best regards George P. Banyard
  105517
April 30, 2019 15:00 zeev@php.net (Zeev Suraski)
On Tue, Apr 30, 2019 at 2:14 PM G. P. B. banyard@gmail.com> wrote:

> On Mon, 29 Apr 2019 at 16:53, Zeev Suraski <zeev@php.net> wrote: > >> On Mon, Apr 29, 2019 at 5:19 PM Dan Ackroyd <Danack@basereality.com> >> wrote: >> > Please stop doing this. >> >> I will gladly do so, once the project starts behaving responsibly again. >> > > Honnestly, this comment right here Zeev just makes me want to not > compromise at all. > I think you seriously lost any hope there was that I'm going to put back > this to a vote. >
In retrospect, I should have waited for Dan's insulting message to wear off before replying to it. The fact the RFC included a confusing secondary vote, that was defined against our RFC rules and may have been misunderstood by folks who voted (and consequently may have resulted in different outcomes) - is sufficient grounds to disqualify this vote and require a restarted vote on a fixed RFC (that can include the amendments you have in mind to make the 8.0 behavior different from what the RFC proposed). Zeev
  105518
April 30, 2019 16:03 levim@php.net (Levi Morrison)
On Tue, Apr 30, 2019 at 9:01 AM Zeev Suraski <zeev@php.net> wrote:
> > On Tue, Apr 30, 2019 at 2:14 PM G. P. B. banyard@gmail.com> wrote: > > > On Mon, 29 Apr 2019 at 16:53, Zeev Suraski <zeev@php.net> wrote: > > > >> On Mon, Apr 29, 2019 at 5:19 PM Dan Ackroyd <Danack@basereality.com> > >> wrote: > >> > Please stop doing this. > >> > >> I will gladly do so, once the project starts behaving responsibly again. > >> > > > > Honnestly, this comment right here Zeev just makes me want to not > > compromise at all. > > I think you seriously lost any hope there was that I'm going to put back > > this to a vote. > > > > In retrospect, I should have waited for Dan's insulting message to wear off > before replying to it. > > The fact the RFC included a confusing secondary vote, that was defined > against our RFC rules and may have been misunderstood by folks who voted > (and consequently may have resulted in different outcomes) - is sufficient > grounds to disqualify this vote and require a restarted vote on a fixed RFC > (that can include the amendments you have in mind to make the 8.0 behavior > different from what the RFC proposed). > > Zeev
I read our voting rules, checked with a few people, and thought about it for a while, and I still do not know what rule breakage you are referring to. How did this supposedly break our voting rules? If you want any support on disqualifying this RFC, you need to clearly state the violation.
  105521
April 30, 2019 18:14 zeev@php.net (Zeev Suraski)
On Tue, Apr 30, 2019 at 7:03 PM Levi Morrison <levim@php.net> wrote:

> On Tue, Apr 30, 2019 at 9:01 AM Zeev Suraski <zeev@php.net> wrote: > > > > On Tue, Apr 30, 2019 at 2:14 PM G. P. B. banyard@gmail.com> > wrote: > > > > > On Mon, 29 Apr 2019 at 16:53, Zeev Suraski <zeev@php.net> wrote: > > > > > >> On Mon, Apr 29, 2019 at 5:19 PM Dan Ackroyd <Danack@basereality.com> > > >> wrote: > > >> > Please stop doing this. > > >> > > >> I will gladly do so, once the project starts behaving responsibly > again. > > >> > > > > > > Honnestly, this comment right here Zeev just makes me want to not > > > compromise at all. > > > I think you seriously lost any hope there was that I'm going to put > back > > > this to a vote. > > > > > > > In retrospect, I should have waited for Dan's insulting message to wear > off > > before replying to it. > > > > The fact the RFC included a confusing secondary vote, that was defined > > against our RFC rules and may have been misunderstood by folks who voted > > (and consequently may have resulted in different outcomes) - is > sufficient > > grounds to disqualify this vote and require a restarted vote on a fixed > RFC > > (that can include the amendments you have in mind to make the 8.0 > behavior > > different from what the RFC proposed). > > > > Zeev > > I read our voting rules, checked with a few people, and thought about > it for a while, and I still do not know what rule breakage you are > referring to. How did this supposedly break our voting rules? If you > want any support on disqualifying this RFC, you need to clearly state > the violation. >
The Voting RFC states: "Additionally, an RFC may have secondary votes, which are used to *decide implementation details*. " (emphasis added) The RFC in question states: "Secondary vote: Remove PHP's short open tags in PHP 8.0." This is not an implementation detail or even remotely one. It's makes a huge difference, arguably a lot bigger than the primary vote (which can be fairly easily ignored by end users). This is not a technicality. I found the voting options very confusing, and I'm sure I wasn't the only one. In addition, I found it very weird that many folks voted NOT to deprecate this feature in 7.4, but voted in favour of removing it in 8.0 - which doesn't go against any of our RFCs (at least if my memory serves me right), but does go against the way we've been handling deprecations in the last ~15 years - you never remove a feature without deprecating it first. So in addition to stating a secondary vote for something that had to be a primary vote - the 'original' primary vote (deprecate in 7.4) is in fact an inherent requirement if the secondary vote passes - but judging from people's votes, it's clear it wasn't properly understood. George has a reasonable interpretation as to what this meant - but it's just one possible interpretation. Ultimately, the voting decisions were flawed and against two of our rules (one written, and one de-facto) - which means that needs to be fixed and redone. It's impossible to know what kind of impact laying out the voting options properly would have had (it goes in both directions, by the way - it may have resulted in a higher majority - or a lower one, pushing it below the threshold). On the substance level - I think it's clear even to the pro-deprecation crowd that this RFC was created in haste. There was very little discussion over it, so little that the fact that the fact that outright removing short tags in 8.0 (as opposed to turning them into errors) would have catastrophic consequences wasn't even discussed. I've heard from several folks that the right way to address this is with a new RFC that will supercede this one. I agree, but it should be the authoritative RFC with the current one being annulled - given the flawed voting options. We need a new RFC that fixes the flaws of the current one - both in terms of substance (8.0 behavior) and voting options. Zeev
  105522
April 30, 2019 18:16 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> Why the hell should I start compromising with someone who thinks the > project, and by > extensions the contributors to the project small or large, don't behave > responsibly?!
Without getting into generalities about all contributors over all the project lifetime, I personally think what happened with this RFC falls short of the ideal RFC process as we'd like to see it happen in PHP. See below on that. I don't think it's useful to assign personal blame for anything here, but I think it may be useful to try and find the ways how to improve.
> You say that this deprecation is an insult to our legacy users but you just > casually > insult (at least in my mind) the people who make this project live on. > Or are you just remicinent of ye olden days where core devs decided willy > nilly what > ever they want to do with the project? Because I though the whole idea > behind the RFC > process is to prevent this "closed club" of core dev who can decide > whatever they want.
There are downsides to that. For example, people voting on RFCs without actually realizing the full extent of what they are voting for. Like voting for a change that will start dumping people's sources to the internet once implemented - without even realizing that would happen. I don't know, of course, how many of the people voting yes didn't realize that and how many did but did not care - but the following discussion shows that this definitely wasn't properly discussed because otherwise there wouldn't be any point in discussing it anew. And the solutions proposed so far negate at least half of proposed benefits from the RFC. So I am thinking - was what happened a good example of a good working process? Do we think the situation where we're talking about changing the approach days after the vote is how RFCs should work? I personally think that the fact that RFC was voted in without considering a critical BC issue and without even acknowledging it in the RFC shows we are way too hasty to introduce breaking changes and do not spend enough thought on evaluating their effects on existing users. It's very easy to ask people "do you hate short tags?" and get a resounding "yes". If you asked "do you want any old code that might use slightly older Smarty or some other not-recently-updated dependency suddenly spill its guts to the internet starting with 7.4?", the "yes" might be much less enthusiastic. But that question wasn't asked. And asking that question - the right question - is our job here. Which, in my opinion, in this case wasn't done properly - before voting on the RFC. Good that at least we're doing it after.
> I was willing to compromise a lot but with all the respect I have for you > Zeev, your sheer arogance > just made any major compromise not a thing I want to pursue anymore.
This phrasing looks suspiciously like you're basing your decisions in the matter not on technical merits and concerns about PHP project and its users, but on your personal grudges. I am certainly hoping this is just because of an unartful turn of phrase and you want to rephrase that in a way that does not give this impression. -- Stas Malyshev smalyshev@gmail.com
  105419
April 24, 2019 22:10 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

>> A friendly reminder that some people are hosting customer code which they >> do not want to touch but will get support requests once the code breaks. >> >> - Chris >> > > That's normal? Everyone has projects to maintain, and breaking changes are > common: they're gonna call you for one anyway: if you don't like that, then > you are in the wrong line of business.
I think answering to a valid concern that certain change would increase breakage and maintenance load with "well, that's what you're paid for, right?" is not what we expect from the discussion on this list. It's dismissing rather than discussing. Let's have less of that on the list. -- Stas Malyshev smalyshev@gmail.com
  105373
April 24, 2019 14:33 r@roze.lv ("Reinis Rozitis")
> A 68% majority which barely clears the 2/3 requirements for something as > fundamental as that - with so many core devs against it - we'll deserve all the > criticism that will be coming our way in 7.4/8.0 from end users wondering why > we needlessly broke their apps and made migration a bit more of a headache.
It's quite interesting to check the karma levels for the voters (might be on a slippery slope here but it feels a bit unfair that someone with just a documentation karma (or no karma at all (at least according to wiki.php.net)) has the same weight on a core option getting removed). p.s. at least for the deprecation stage for 7.4 the revert patch is simple rr
  105383
April 24, 2019 16:03 mails@thomasbley.de (Thomas Bley)
Hello,

I understand that breaking changes always need extra work, but in this case I think it's a quick change. On my code base (mostly legacy with 1.8m lines), I ran this and got 10 matches to check:

grep -rin "> vsuraski@gmail.com hat am 24. April 2019 um 15:41 geschrieben:
> 
> 
> FWIW,
> 
> I think it's a bad decision, made against the thoughts of clear majority of core developers - and for hardly a good reason. I believe it illustrates very well why we need to properly define our voting eligibility rules, and I hope someone would be up to the challenge of tackling it (I decided not to pursue it further after the 'abolish' RFC(s)).
> 
> A 68% majority which barely clears the 2/3 requirements for something as fundamental as that - with so many core devs against it - we'll deserve all the criticism that will be coming our way in 7.4/8.0 from end users wondering why we needlessly broke their apps and made migration a bit more of a headache.
> 
> My 2c.
> 
> Zeev
> 
> 
> -----Original Message-----
> From: G. P. B. banyard@gmail.com> 
> Sent: Wednesday, April 24, 2019 2:29 PM
> To: PHP internals <internals@lists.php.net>
> Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
> 
> Hello Internal,
> 
> The two weeks of voting have now ended.
> The results are 38 for and 18 against (total 56) for the primary vote to deprecate PHP's short open tag in PHP 7.4.
> This passes in favor with 68%.
> 
> The results are 42 for and 15 against (total 57) for the secondary vote to remove PHP's short open tag in PHP 8.
> This passes in favor with 74%.
> 
> Thanks for everyone who voted on this issue.
> 
> Best regards
> 
> George P. Banyard
> 
> >
> 
> 
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
  105386
April 24, 2019 16:08 chasepeeler@gmail.com (Chase Peeler)
On Wed, Apr 24, 2019 at 12:03 PM Thomas Bley <mails@thomasbley.de> wrote:

> Hello, > > I understand that breaking changes always need extra work, but in this > case I think it's a quick change. On my code base (mostly legacy with 1.8m > lines), I ran this and got 10 matches to check: > > Awesome. I got 6,787 over 4m lines.
> grep -rin " -v "\.js:" > > Regards > Thomas > > > vsuraski@gmail.com hat am 24. April 2019 um 15:41 geschrieben: > > > > > > FWIW, > > > > I think it's a bad decision, made against the thoughts of clear majority > of core developers - and for hardly a good reason. I believe it illustrates > very well why we need to properly define our voting eligibility rules, and > I hope someone would be up to the challenge of tackling it (I decided not > to pursue it further after the 'abolish' RFC(s)). > > > > A 68% majority which barely clears the 2/3 requirements for something as > fundamental as that - with so many core devs against it - we'll deserve all > the criticism that will be coming our way in 7.4/8.0 from end users > wondering why we needlessly broke their apps and made migration a bit more > of a headache. > > > > My 2c. > > > > Zeev > > > > > > -----Original Message----- > > From: G. P. B. banyard@gmail.com> > > Sent: Wednesday, April 24, 2019 2:29 PM > > To: PHP internals <internals@lists.php.net> > > Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags > > > > Hello Internal, > > > > The two weeks of voting have now ended. > > The results are 38 for and 18 against (total 56) for the primary vote to > deprecate PHP's short open tag in PHP 7.4. > > This passes in favor with 68%. > > > > The results are 42 for and 15 against (total 57) for the secondary vote > to remove PHP's short open tag in PHP 8. > > This passes in favor with 74%. > > > > Thanks for everyone who voted on this issue. > > > > Best regards > > > > George P. Banyard > > > > > > > > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- Chase Peeler chasepeeler@gmail.com
  105401
April 24, 2019 17:55 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> A 68% majority which barely clears the 2/3 requirements for something as > fundamental as that - with so many core devs against it - we'll deserve all > the criticism that will be coming our way in 7.4/8.0 from end users > wondering why we needlessly broke their apps and made migration a bit more > of a headache.
I agree. I think it will be a mistake to do this, and it will hurt a lot of people upgrading to 7.4, and people who voted "yes" seriously underestimate how much old code is out there. And the benefit of this change for the user is virtually non-existant (in fact, one of the listed benefits - "As such source code may leak if PHP relying on the short open tags is executed on a configuration where this isn't enabled" - is exactly the situation that would happen when the RFC is implemented). -- Stas Malyshev smalyshev@gmail.com
  105411
April 24, 2019 20:47 bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)
Den 2019-04-24 kl. 19:55, skrev Stanislav Malyshev:
> Hi! > >> A 68% majority which barely clears the 2/3 requirements for something as >> fundamental as that - with so many core devs against it - we'll deserve all >> the criticism that will be coming our way in 7.4/8.0 from end users >> wondering why we needlessly broke their apps and made migration a bit more >> of a headache. > I agree. I think it will be a mistake to do this, and it will hurt a lot > of people upgrading to 7.4, and people who voted "yes" seriously > underestimate how much old code is out there. And the benefit of this > change for the user is virtually non-existant (in fact, one of the > listed benefits - "As such source code may leak if PHP relying on the > short open tags is executed on a configuration where this isn't enabled" > - is exactly the situation that would happen when the RFC is implemented).
Hi, I recall the discussion about extending the support for 7.4 like we had for 5.6, see: - https://externals.io/message/104581#104807 I read the discussion as it was rejected, but features like this would benefit from it, since not only "inhouse" code will need to adapt but also libraries. So with this feature we put more weight in the migration bucket, but not so much benefit. Are we then willing to extend the support for PHP 7.4 given features like this? Other BC breaking features will of course also benefit ;-) r//Björn L
  105414
April 24, 2019 21:35 narf@devilix.net (Andrey Andreev)
Hello,

I personally am not happy with the outcome of the vote. I think
there's no practical benefit to be gained from the proposal and I
don't even understand what has urged the author to make it; I voted No
on both questions.

However, what's done is done and these post-vote protests are getting
ridiculous. Where were you all during discussion and even during the
voting period? I only remember a single person's rant here and barely
any comments on social media about it ... The people who voted Yes may
have weak arguments ("there's tools out there" isn't a good argument
in my book), they may've underestimated the impact of the change or
they may not even care about it. But they cared enough to drop by and
make their views count, while almost nobody cared enough to come here
and say this isn't right. We don't get to force-reverse a decision
that we didn't care enough for when it mattered.

Cheers,
Andrey.
  105420
April 24, 2019 22:18 bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)
Den 2019-04-24 kl. 23:35, skrev Andrey Andreev:
> Hello, > > I personally am not happy with the outcome of the vote. I think > there's no practical benefit to be gained from the proposal and I > don't even understand what has urged the author to make it; I voted No > on both questions. > > However, what's done is done and these post-vote protests are getting > ridiculous. Where were you all during discussion and even during the > voting period? I only remember a single person's rant here and barely > any comments on social media about it ... The people who voted Yes may > have weak arguments ("there's tools out there" isn't a good argument > in my book), they may've underestimated the impact of the change or > they may not even care about it. But they cared enough to drop by and > make their views count, while almost nobody cared enough to come here > and say this isn't right. We don't get to force-reverse a decision > that we didn't care enough for when it mattered. > > Cheers, > Andrey. You are absolutely right! The only excuse for myself during the
discussion etc was that I thought it never would pass, so I "slept"... One thing to consider though is if the BC break together with other features is big enough to justify extended support for 7.4? r//Björn L
  105423
April 24, 2019 23:43 cmbecker69@gmx.de ("Christoph M. Becker")
On 24.04.2019 at 22:47, Björn Larsson wrote:

> I recall the discussion about extending the support for 7.4 like we had > for 5.6, see: > - https://externals.io/message/104581#104807 > > I read the discussion as it was rejected, but features like this would > benefit from it, > since not only "inhouse" code will need to adapt but also libraries. > > So with this feature we put more weight in the migration bucket, but not > so much > benefit. Are we then willing to extend the support for PHP 7.4 given > features like > this? Other BC breaking features will of course also benefit ;-)
We had an RFC regarding the PHP 5 support timeline[1], so why not have an RFC regarding the PHP 7 support timeline? Any volunteers? [1] <https://wiki.php.net/rfc/php56timeline> -- Christoph M. Becker
  105377
April 24, 2019 14:56 peterkokot@gmail.com (Peter Kokot)
Hello,

On Wed, 24 Apr 2019 at 13:29, G. P. B. banyard@gmail.com> wrote:
> > Hello Internal, > > The two weeks of voting have now ended. > The results are 38 for and 18 against (total 56) for the primary vote to > deprecate PHP's short open tag in PHP 7.4. > This passes in favor with 68%. > > The results are 42 for and 15 against (total 57) for the secondary vote to > remove PHP's short open tag in PHP 8. > This passes in favor with 74%. > > Thanks for everyone who voted on this issue. > > Best regards > > George P. Banyard > > >
Great! It was about time this got removed. And it is a perfect timing also - PHP 8.0 when BC breaking changes can be done. Thank you so much for moving this forward. People who are thinking of supporting some legacy applications on the upcoming PHP 8 will be unfortunately a bit surprised with all the removed features and will have other bigger issues adjusting their code compared to a really simple replace of
  105410
April 24, 2019 20:32 bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)
Den 2019-04-24 kl. 16:56, skrev Peter Kokot:
> Hello, > > On Wed, 24 Apr 2019 at 13:29, G. P. B. banyard@gmail.com> wrote: >> Hello Internal, >> >> The two weeks of voting have now ended. >> The results are 38 for and 18 against (total 56) for the primary vote to >> deprecate PHP's short open tag in PHP 7.4. >> This passes in favor with 68%. >> >> The results are 42 for and 15 against (total 57) for the secondary vote to >> remove PHP's short open tag in PHP 8. >> This passes in favor with 74%. >> >> Thanks for everyone who voted on this issue. >> >> Best regards >> >> George P. Banyard >> > Great! It was about time this got removed. And it is a perfect timing > also - PHP 8.0 when BC breaking changes can be done. Thank you so much > for moving this forward. People who are thinking of supporting some > legacy applications on the upcoming PHP 8 will be unfortunately a bit > surprised with all the removed features and will have other bigger > issues adjusting their code compared to a really simple replace of with about. > > I think this is a good move. > > > -- > Peter Kokot
Hi, I agree on this to some degree when it comes to your own code that you control. But, imagine a relatively big open source library that is maintained with small resources. One example I have myself is using a relatively large & well established open source library where I'm using the latest version released before Christmas. I run the site on PHP 7.3, but I still get warnings regarding the RFC Counting of non-countable objects for PHP 7.2 related to this library. With that experience in mind I wonder how different libraries will fare, given this change? One should also have in mind that there has been a discussion on this list about extending the support cycle for PHP 7.4 like for 5.6, but to some degree it was rejected which doesn't help migration efforts. r//Björn L
  105412
April 24, 2019 21:02 markyr@gmail.com (Mark Randall)
On 24/04/2019 21:32, Björn Larsson wrote:
> With that experience in mind I wonder how different libraries will fare, > given this > change? One should also have in mind that there has been a discussion on > this list about extending the support cycle for PHP 7.4 like for 5.6, but to > some degree it was rejected which doesn't help migration efforts.
I'm sure Nikita will pop up sometime in the next few days and put his recently downloaded 1000+ packages through his parser and give us some figures on how many use short open tags, if he hasn't already done so. I would naturally expect it to be extremely small, after all it makes no sense to have a public package which requires a language feature to be enabled in the INI and which can't be relied upon. If there's a problem, it will almost certainly be with internal code, which naturally there's a few million times more of, but that seems very much in-scope for individual developers to fix if they want to upgrade to PHP 8. My main worry is, and remains, that it's being converted to just a "not parser significant" in PHP 8. The potential for unexpected data / code leaks is *significant*. Until someone can convince me otherwise, I will continue to strongly believe that
  105430
April 25, 2019 07:11 thruska@cubiclesoft.com (Thomas Hruska)
On 4/24/2019 4:28 AM, G. P. B. wrote:
> Hello Internal, > > The two weeks of voting have now ended. > The results are 38 for and 18 against (total 56) for the primary vote to > deprecate PHP's short open tag in PHP 7.4. > This passes in favor with 68%. > > The results are 42 for and 15 against (total 57) for the secondary vote to > remove PHP's short open tag in PHP 8. > This passes in favor with 74%. > > Thanks for everyone who voted on this issue. > > Best regards > > George P. Banyard
Since this has passed, I would like to discuss official tool recommendations when 7.4 and 8 are published. Because users are going to want that. sed-based solutions do NOT work. PHP is a complex language and it requires using the tokenizer to properly replace short open tags. The PHP-CS-Fixer FullOpeningTag fixer is also completely broken software - it actually misses common use-cases and it intentionally damages code and then attempts (and in some cases fails) to revert the damage in the process. Neither of the two recommended options to date on this list are valid recommendations for serious software deployment managers. I also looked at a number of other tools that have popped up on my radar and found nothing that met my basic criteria of: - Total control over the transformation process, favoring analysis over modification. - Zero regexes and relying solely on token_get_all(). - Does exactly one thing and does it well in as little code as possible so it can be easily vetted by others. So I built a tool that meets the above minimum criteria and have already run it against a fairly extensive codebase (and have shared the tool with a few concerned folks - you've already seen its output here on-list): https://github.com/cubiclesoft/php-short-open-tag-finder/ The included test suite (test.php), while a mere 14 lines, presents suitably difficult scenarios to correctly handle both situations of having (pre-PHP 8) and not having (post-PHP 8) short open tag support. The tool correctly parses the test suite in both modes without using any regexes. The only downside to the tool is that the 'Y' key on a keyboard might get broken in the optional '-ask' mode. I did experience a bit of fatigue with using the tool to modify several thousand files with short open tags but the transformation was otherwise flawless (i.e. no false positives or false negatives) and was end-user transparent (i.e. didn't break anything in production) other than having to go back and do git-commits on all of the 70+ affected projects afterwards. I recommend having a short list of vetted, verified tools that meet specific criteria. Tools that just walk down a directory tree and bulk modify by default, those that rely on regexes, and those that require short tags to be enabled to function should all be rejected from consideration. Recommended tools should also be able to be run by a wide range of users, including hosting providers who might want to inform their customers that use short open tags when they plan on upgrading the host to PHP 8 that they have code on their website that will probably break. In summary, I went ahead and wrote a tool, ran it against 9.4 million lines of real production code, then ran it in '-ask' mode and let it carefully modify a few thousand files by mashing my 'Y' key a bunch of times pausing briefly to look at interesting changes (which really only took a couple of hours and probably lowered the lifespan of that key on the keyboard a bit). I hope others can benefit from the tool too. -- 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/
  105432
April 25, 2019 07:26 php-lists@koalephant.com (Stephen Reay)
> On 25 Apr 2019, at 14:11, Thomas Hruska <thruska@cubiclesoft.com> wrote: > sed-based solutions do NOT work. > Neither of the two recommended options to date on this list are valid recommendations for serious software deployment managers.
I have no issue with suggesting tools to fix short opening tags, but lay off the absolute statements. The approaches mentioned literally do work (because the people who mentioned them used them), they just may not work *for your codebase*.
  105436
April 25, 2019 08:06 thruska@cubiclesoft.com (Thomas Hruska)
On 4/25/2019 12:26 AM, Stephen Reay wrote:
> >> On 25 Apr 2019, at 14:11, Thomas Hruska <thruska@cubiclesoft.com> wrote: >> sed-based solutions do NOT work. >> Neither of the two recommended options to date on this list are valid recommendations for serious software deployment managers. > > > I have no issue with suggesting tools to fix short opening tags, but lay off the absolute statements. > > The approaches mentioned literally do work (because the people who mentioned them used them), they just may not work *for your codebase*.
Both the sed and PHP-CS-Fixer solutions recommended on this list would have broken several of my production applications AND failed to provide a complete conversion in the process. Hopefully that explains where my statement came from. Apologies if I came on too strongly here. I still think that software that works only on a subset of PHP code is a recipe for disaster. -- 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/
April 25, 2019 07:57 come@opensides.be (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Le jeudi 25 avril 2019, 00:11:42 CEST Thomas Hruska a écrit :
> So I built a tool that meets the above minimum criteria and have already > run it against a fairly extensive codebase (and have shared the tool > with a few concerned folks - you've already seen its output here on-list): > > https://github.com/cubiclesoft/php-short-open-tag-finder/
«// (C) 2019 CubicleSoft. All Rights Reserved.» does not meet my minimum criteria.
> Tools that just walk down a directory tree and bulk > modify by default, […] should all be rejected from > consideration.
I do not understand why you have a problem with this, the rest of your email seems to suggest you are using git. Just run the tool and then look at the diff before committing anything. This makes *way* more sense than having to manually review each change one by one. Côme
  105437
April 25, 2019 08:21 thruska@cubiclesoft.com (Thomas Hruska)
On 4/25/2019 12:57 AM, Côme Chilliet wrote:
> Le jeudi 25 avril 2019, 00:11:42 CEST Thomas Hruska a écrit : >> So I built a tool that meets the above minimum criteria and have already >> run it against a fairly extensive codebase (and have shared the tool >> with a few concerned folks - you've already seen its output here on-list): >> >> https://github.com/cubiclesoft/php-short-open-tag-finder/ > > «// (C) 2019 CubicleSoft. All Rights Reserved.» does not meet my minimum criteria.
From the README: * Has a liberal open source license. MIT or LGPL, your choice. Not sure what the problem is here.
>> Tools that just walk down a directory tree and bulk >> modify by default, […] should all be rejected from >> consideration. > > I do not understand why you have a problem with this, the rest of your email seems to suggest you are using git. > Just run the tool and then look at the diff before committing anything. > > This makes *way* more sense than having to manually review each change one by one.
I err on the side of caution for a variety of reasons that are off-topic for this list/thread. -- 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/
  105438
April 25, 2019 08:22 thruska@cubiclesoft.com (Thomas Hruska)
On 4/24/2019 4:28 AM, G. P. B. wrote:
> Hello Internal, > > The two weeks of voting have now ended. > The results are 38 for and 18 against (total 56) for the primary vote to > deprecate PHP's short open tag in PHP 7.4. > This passes in favor with 68%. > > The results are 42 for and 15 against (total 57) for the secondary vote to > remove PHP's short open tag in PHP 8. > This passes in favor with 74%. > > Thanks for everyone who voted on this issue. > > Best regards > > George P. Banyard
By the way, has anyone thought about the GDPR impact of this change? -- 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/
  105443
April 25, 2019 10:03 kontakt@beberlei.de (Benjamin Eberlei)
On Wed, Apr 24, 2019 at 1:29 PM G. P. B. banyard@gmail.com> wrote:

> Hello Internal, > > The two weeks of voting have now ended. > The results are 38 for and 18 against (total 56) for the primary vote to > deprecate PHP's short open tag in PHP 7.4. > This passes in favor with 68%. > > The results are 42 for and 15 against (total 57) for the secondary vote to > remove PHP's short open tag in PHP 8. > This passes in favor with 74%. > > Thanks for everyone who voted on this issue. > > Best regards > > George P. Banyard >
The RFC doesn't mention to much details on the exact implementation of this removal, but to avoid the potential security nightmare of > > > >
  105235
April 11, 2019 08:50 php-lists@koalephant.com (Stephen Reay)
> On 11 Apr 2019, at 04:49, Wes php@gmail.com> wrote: > > The > whole community (not just you) considers short open tags poison because not > XML-compatible... while they use stuff like twig, which is also not > XML-compatible.
I can’t say I’ve run into the XML issue in a real environment, but IMO the big ‘problem’ is that they can be disabled, so they can’t be relied upon for anything being distributed outside your own direct control. Also for the record, *I* don’t use Twig (The one thing no one can deny is php’s power as a markup templating language.. and then people don’t use it directly? Insanity.) Cheers Stephen
  105236
April 11, 2019 10:14 petercowburn@gmail.com (Peter Cowburn)
On Wed, 10 Apr 2019 at 11:44, G. P. B. banyard@gmail.com> wrote:

> Hello Internals, > > As there have been no further comments the voting for my RFC [1] to > deprecate PHP's > short open tags has started and will run for two (2) weeks. >
Firstly, I apologize for not mentioning this before the vote was opened. Does the primary (it's probably not fair to call it that, for this RFC) vote include changing the default (php -n) from On to Off? That's what is specified in the very concise proposal section, so it seems reasonable to assume it's the case, but I just want to be sure since the actual vote question doesn't mention changing the default value. With the current state of voting, it is looking like we could end up such that we don't deprecate (and disable by default, maybe) the feature, but jump straight to removing it. That's not usually how feature removal works. It would've been better, IMO, to just take the proposal ("Deprecate and disable short_open_tag in PHP 7.4 and remove PHP's short open tags in PHP 8.0.") and make that a yes/no vote. Best regards
  105237
April 11, 2019 10:27 george.banyard@gmail.com ("G. P. B.")
On Thu, 11 Apr 2019 at 12:14, Peter Cowburn <petercowburn@gmail.com> wrote:

> > > On Wed, 10 Apr 2019 at 11:44, G. P. B. banyard@gmail.com> wrote: > >> Hello Internals, >> >> As there have been no further comments the voting for my RFC [1] to >> deprecate PHP's >> short open tags has started and will run for two (2) weeks. >> > > Firstly, I apologize for not mentioning this before the vote was opened. > > Does the primary (it's probably not fair to call it that, for this RFC) > vote include changing the default (php -n) from On to Off? That's what is > specified in the very concise proposal section, so it seems reasonable to > assume it's the case, but I just want to be sure since the actual vote > question doesn't mention changing the default value. > > With the current state of voting, it is looking like we could end up such > that we don't deprecate (and disable by default, maybe) the feature, but > jump straight to removing it. That's not usually how feature removal > works. It would've been better, IMO, to just take the proposal > ("Deprecate and disable short_open_tag in PHP 7.4 and remove PHP's short > open tags in PHP 8.0.") and make that a yes/no vote. >
Hello Peter, For changing the default from On to Off it more something I realised during the implementation of the patch that the in-engine default is "On", which I found to be unexpected (probably because the doc says it's only enabled with a compile flag) so I changed it. But the default could stay the same as I'm starting to realise that with current state of voting we are getting kind of a mess of a split vote as you said. It would have been nice that someone would have noticed the problems with the voting structure before I start it but not to sure how to proceed. I don't know if people vote against the deprecation notice in PHP 7.4 as the default value changes because if this is the case maybe leaving the default as is and only deprecating would be better? Also I do agree that having deprecation notices before a feature removal is wise but from my understanding the RFC which removed the ASP tags also didn't have deprecation notices, so there is already a precedent for removing features without warning (not that I agree with it). So not sure how to proceed ATM and some more feedback would be probably necessary as it is my first RFC. Best regards George P. Banyard
  105488
April 28, 2019 20:39 peterkokot@gmail.com (Peter Kokot)
Hello,

On Wed, 10 Apr 2019 at 12:44, G. P. B. banyard@gmail.com> wrote:
> > Hello Internals, > > As there have been no further comments the voting for my RFC [1] to > deprecate PHP's > short open tags has started and will run for two (2) weeks. > > Best regards > > George P. Banyard > > [1] https://wiki.php.net/rfc/deprecate_php_short_tags
I want to thank you for this RFC, for your time dedicated to it, for the actual implementation and everything. You have done everything correct and also the general idea i.e. removing these legacy tags in either PHP 8.0 or not was completely correctly pointed out and RFC (at least according to the current PHP RFC standards) met all the criteria to get into implementation step. Everyone who is working with PHP development knows that these short tags are not meant to be used anymore. Also everything was correctly accepted and the numbers are correct. This entire thread is also showing the integrity, intelligence level of the PHP a bit but one day maybe these legacy leftovers can be removed, hopefully... Because they really should. So let's not give up and let's find some normal solution here... RFC and results are quite clear but maybe Nikita's solution is good enough for all: - Deprecation warnings in PHP 7.4 (RFC criteria met, people here happy or not) - PHP 8.0 complete compile error without any option to further use them anymore (RFC criteria sort of met -!!!, and the reason of pretending that the legacy apps will work ok on PHP 8.0 also met) - Actual removal in PHP 9 (because this is then the logical next step). Removing something like this in PHP 8.1 is not following semantic versioning at all. Either removal in 8.0 or 9.0. Cheers and thanks. -- Peter Kokot