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