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

  106384
August 6, 2019 11:34 george.banyard@gmail.com ("G. P. B.")
The voting for the "Deprecate short open tags, again" [1] RFC has begun.
It is expected to last two (2) weeks until 2019-08-20.

A counter argument to this RFC is available at
https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags

Best regards

George P. Banyard

[1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2
  106391
August 6, 2019 16:59 chasepeeler@gmail.com (Chase Peeler)
I'm not a voter, but, I have a question. If this fails, does that mean the
original RFC that passed is still in effect?

If I did have a vote, I would be against this RFC for the reasons laid out
by Zeev in the counter argument. However, I feel the negative impacts of
possible code leaks that will be caused by the original RFC are even worse.
If I did have a vote, I might feel forced to vote for this. At least with
this RFC we wouldn't really see any of the other negative impacts until PHP
9, given us time to revisit and possibly reverse that part of this RFC.

On Tue, Aug 6, 2019 at 7:34 AM G. P. B. banyard@gmail.com> wrote:

> The voting for the "Deprecate short open tags, again" [1] RFC has begun. > It is expected to last two (2) weeks until 2019-08-20. > > A counter argument to this RFC is available at > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags > > Best regards > > George P. Banyard > > [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2 >
-- Chase Peeler chasepeeler@gmail.com
  106392
August 6, 2019 17:11 rowan.collins@gmail.com (Rowan Collins)
On Tue, 6 Aug 2019 at 17:59, Chase Peeler <chasepeeler@gmail.com> wrote:

> I'm not a voter, but, I have a question. If this fails, does that mean the > original RFC that passed is still in effect? >
Yes, this is really ambiguous, and risks the situation being even more confusing than it was before. The "No" column on this RFC already includes people who voted "Yes" on the previous version; is this an indication that they have changed their mind about removing short tags, or that they prefer the original proposal? I think we urgently need to clarify this, and may need to reset the vote with one or more clearer questions. Regards, -- Rowan Collins [IMSoP]
  106393
August 6, 2019 17:19 george.banyard@gmail.com ("G. P. B.")
On Tue, 6 Aug 2019 at 19:12, Rowan Collins collins@gmail.com> wrote:

> On Tue, 6 Aug 2019 at 17:59, Chase Peeler <chasepeeler@gmail.com> wrote: > > > I'm not a voter, but, I have a question. If this fails, does that mean > the > > original RFC that passed is still in effect? > > > > > Yes, this is really ambiguous, and risks the situation being even more > confusing than it was before. > > The "No" column on this RFC already includes people who voted "Yes" on the > previous version; is this an indication that they have changed their mind > about removing short tags, or that they prefer the original proposal? > > I think we urgently need to clarify this, and may need to reset the vote > with one or more clearer questions. > > Regards, > -- > Rowan Collins > [IMSoP]
This RFC supersedes the previous one as stated in the the RFC itself : " This RFC supersedes the previous one and proposes a different deprecation approach." meaning that the previous one is void. I don't know why this is ambiguous and needs to be said once again. Best regards George P. Banyard
  106394
August 6, 2019 17:23 peterkokot@gmail.com (Peter Kokot)
Hello,

On Tue, 6 Aug 2019 at 19:19, G. P. B. banyard@gmail.com> wrote:
> > On Tue, 6 Aug 2019 at 19:12, Rowan Collins collins@gmail.com> wrote: > > > On Tue, 6 Aug 2019 at 17:59, Chase Peeler <chasepeeler@gmail.com> wrote: > > > > > I'm not a voter, but, I have a question. If this fails, does that mean > > the > > > original RFC that passed is still in effect? > > > > > > > > > Yes, this is really ambiguous, and risks the situation being even more > > confusing than it was before. > > > > The "No" column on this RFC already includes people who voted "Yes" on the > > previous version; is this an indication that they have changed their mind > > about removing short tags, or that they prefer the original proposal? > > > > I think we urgently need to clarify this, and may need to reset the vote > > with one or more clearer questions. > > > > Regards, > > -- > > Rowan Collins > > [IMSoP] > > > This RFC supersedes the previous one as stated in the the RFC itself : " > This RFC supersedes the previous one and proposes a different deprecation > approach." meaning that the previous one is void. > I don't know why this is ambiguous and needs to be said once again. > > Best regards > > George P. Banyard
Thank you for clarification. From what I understand it is the case where "no" means a status quo and no agreements has been reached on the original RFC. Since the original RFC has been vetoed and so much energy was invested from Zeev and some others commentators then I guess the RFCs fail and we will have two types of opening tags in PHP for ever. Otherwise, as described, yes. -- Peter Kokot
  106395
August 6, 2019 17:25 chasepeeler@gmail.com (Chase Peeler)
On Tue, Aug 6, 2019 at 1:19 PM G. P. B. banyard@gmail.com> wrote:

> > > > On Tue, 6 Aug 2019 at 19:12, Rowan Collins collins@gmail.com> > wrote: > >> On Tue, 6 Aug 2019 at 17:59, Chase Peeler <chasepeeler@gmail.com> wrote: >> >> > I'm not a voter, but, I have a question. If this fails, does that mean >> the >> > original RFC that passed is still in effect? >> > >> >> >> Yes, this is really ambiguous, and risks the situation being even more >> confusing than it was before. >> >> The "No" column on this RFC already includes people who voted "Yes" on the >> previous version; is this an indication that they have changed their mind >> about removing short tags, or that they prefer the original proposal? >> >> I think we urgently need to clarify this, and may need to reset the vote >> with one or more clearer questions. >> >> Regards, >> -- >> Rowan Collins >> [IMSoP] > > > This RFC supersedes the previous one as stated in the the RFC itself : " > This RFC supersedes the previous one and proposes a different deprecation > approach." meaning that the previous one is void. > I don't know why this is ambiguous and needs to be said once again. > > Just to clarify - the existence of this RFC effectively means the original never existed.
> Best regards > > George P. Banyard >
-- Chase Peeler chasepeeler@gmail.com
  106396
August 6, 2019 17:27 george.banyard@gmail.com ("G. P. B.")
On Tue, 6 Aug 2019 at 19:25, Chase Peeler <chasepeeler@gmail.com> wrote:

> > > On Tue, Aug 6, 2019 at 1:19 PM G. P. B. banyard@gmail.com> wrote: > >> >> >> >> On Tue, 6 Aug 2019 at 19:12, Rowan Collins collins@gmail.com> >> wrote: >> >>> On Tue, 6 Aug 2019 at 17:59, Chase Peeler <chasepeeler@gmail.com> wrote: >>> >>> > I'm not a voter, but, I have a question. If this fails, does that mean >>> the >>> > original RFC that passed is still in effect? >>> > >>> >>> >>> Yes, this is really ambiguous, and risks the situation being even more >>> confusing than it was before. >>> >>> The "No" column on this RFC already includes people who voted "Yes" on >>> the >>> previous version; is this an indication that they have changed their mind >>> about removing short tags, or that they prefer the original proposal? >>> >>> I think we urgently need to clarify this, and may need to reset the vote >>> with one or more clearer questions. >>> >>> Regards, >>> -- >>> Rowan Collins >>> [IMSoP] >> >> >> This RFC supersedes the previous one as stated in the the RFC itself : " >> This RFC supersedes the previous one and proposes a different >> deprecation approach." meaning that the previous one is void. >> I don't know why this is ambiguous and needs to be said once again. >> >> Just to clarify - the existence of this RFC effectively means the > original never existed. > > >> Best regards >> >> George P. Banyard >> > > > -- > Chase Peeler > chasepeeler@gmail.com >
In a sense yes, however this RFC is a vote on the implementation which would have landed with the previous one but was not the one voted. So you can disregard the result of the previous one not the controversial discussion it generated after the vote was accepted. Hope this clarifies everything. Best regards George P. Banyard
  106403
August 7, 2019 07:28 narf@devilix.net (Andrey Andreev)
Hi,

On Tue, Aug 6, 2019 at 8:20 PM G. P. B. banyard@gmail.com> wrote:
> > This RFC supersedes the previous one as stated in the the RFC itself : " > This RFC supersedes the previous one and proposes a different deprecation > approach." meaning that the previous one is void. > I don't know why this is ambiguous and needs to be said once again. >
As far as I know, there's been no vote to cancel the previously accepted RFC, so ... even though I didn't like the outcome of it, I don't understand how it is just made void now. It's pretty easy to understand the ambiguity. I won't be voting on this one due to all of this. Cheers, Andrey.
  106405
August 7, 2019 08:44 peterkokot@gmail.com (Peter Kokot)
Hello,

On Wed, 7 Aug 2019 at 09:28, Andrey Andreev <narf@devilix.net> wrote:
> > Hi, > > On Tue, Aug 6, 2019 at 8:20 PM G. P. B. banyard@gmail.com> wrote: > > > > This RFC supersedes the previous one as stated in the the RFC itself : " > > This RFC supersedes the previous one and proposes a different deprecation > > approach." meaning that the previous one is void. > > I don't know why this is ambiguous and needs to be said once again. > > > > As far as I know, there's been no vote to cancel the previously > accepted RFC, so ... even though I didn't like the outcome of it, I > don't understand how it is just made void now. It's pretty easy to > understand the ambiguity. > > I won't be voting on this one due to all of this. > > Cheers, > Andrey. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
Yes, last time I was asking this, there was a clarification that certain people from the group internals can veto particular RFC. So, I think that this is the case here. -- Peter Kokot
  106406
August 7, 2019 09:39 cmbecker69@gmx.de ("Christoph M. Becker")
On 07.08.2019 at 10:44, Peter Kokot wrote:

> On Wed, 7 Aug 2019 at 09:28, Andrey Andreev <narf@devilix.net> wrote: > >> On Tue, Aug 6, 2019 at 8:20 PM G. P. B. banyard@gmail.com> wrote: >> >>> This RFC supersedes the previous one as stated in the the RFC itself : " >>> This RFC supersedes the previous one and proposes a different deprecation >>> approach." meaning that the previous one is void. >>> I don't know why this is ambiguous and needs to be said once again. >> >> As far as I know, there's been no vote to cancel the previously >> accepted RFC, so ... even though I didn't like the outcome of it, I >> don't understand how it is just made void now. It's pretty easy to >> understand the ambiguity. >> >> I won't be voting on this one due to all of this. > > Yes, last time I was asking this, there was a clarification that > certain people from the group internals can veto particular RFC. So, I > think that this is the case here.
I'm not aware of *any* veto rights regarding RFCs. As I understand it, this RFC has been put to vote again, because the first version had some problematic details, and by courtesy to cater to the clamor raised after the voting had finished. Thanks, Christoph
  106407
August 7, 2019 10:06 zeev@zend.com (Zeev Suraski)
On 7 Aug 2019, at 12:39, Christoph M. Becker <cmbecker69@gmx.de<mailto:cmbecker69@gmx.de>> wrote:

As I understand it, this RFC has been put to vote again, because the first version had some problematic details, and by courtesy to cater to the clamor raised after
the voting had finished.

That is correct.  There was an inconsistency with the Voting RFC in the voting options, and the RFC (as it passed) also had catastrophic implications for upgrades - so it could not be implemented as it was written.

Zeev
  106410
August 7, 2019 13:55 Danack@basereality.com (Dan Ackroyd)
On Wed, 7 Aug 2019 at 09:45, Peter Kokot <peterkokot@gmail.com> wrote:
> > Yes, last time I was asking this, there was a clarification that > certain people from the group internals can veto particular RFC.
Please could you point to where this alleged rule has ever been written down or agreed to? Although certain people may have claimed this is a rule, it's never been agreed afaik. I think when we adopt a Code of Conduct one of the things we need to make explicit is that "claiming authority that is not codified" is explicitly a thing that will not be allowed in internals discussions as it seems to keep happening and results in a lot of confusion, and frustration. cheers Dan Ack
  106411
August 7, 2019 14:03 phpmailinglists@gmail.com (Peter Bowyer)
On Wed, 7 Aug 2019 at 14:56, Dan Ackroyd <Danack@basereality.com> wrote:

> I think when we adopt a Code of Conduct one of the things we need to > make explicit is that "claiming authority that is not codified" is > explicitly a thing that will not be allowed in internals discussions > as it seems to keep happening and results in a lot of confusion, and > frustration. >
Documenting the project structure would also be helpful. When the PHP Group was mentioned I went hunting for details. I found a list of names at the top of https://www.php.net/credits.php but nothing covering what their role or authority is. Peter
  106412
August 7, 2019 14:09 ben@benramsey.com (Ben Ramsey)
> On Aug 7, 2019, at 09:03, Peter Bowyer <phpmailinglists@gmail.com> wrote: > > On Wed, 7 Aug 2019 at 14:56, Dan Ackroyd <Danack@basereality.com> wrote: > >> I think when we adopt a Code of Conduct one of the things we need to >> make explicit is that "claiming authority that is not codified" is >> explicitly a thing that will not be allowed in internals discussions >> as it seems to keep happening and results in a lot of confusion, and >> frustration. >> > > Documenting the project structure would also be helpful. > > When the PHP Group was mentioned I went hunting for details. I found a list > of names at the top of https://www.php.net/credits.php but nothing covering > what their role or authority is.
Their “role and authority” is copyright ownership of the “code, text, PHP logo, and graphical elements” of the PHP website. https://www.php.net/copyright.php Cheers, Ben
  106414
August 7, 2019 14:16 ben@benramsey.com (Ben Ramsey)
> On Aug 7, 2019, at 09:09, Ben Ramsey <ben@benramsey.com> wrote: > >> On Aug 7, 2019, at 09:03, Peter Bowyer <phpmailinglists@gmail.com> wrote: >> >> On Wed, 7 Aug 2019 at 14:56, Dan Ackroyd <Danack@basereality.com> wrote: >> >>> I think when we adopt a Code of Conduct one of the things we need to >>> make explicit is that "claiming authority that is not codified" is >>> explicitly a thing that will not be allowed in internals discussions >>> as it seems to keep happening and results in a lot of confusion, and >>> frustration. >>> >> >> Documenting the project structure would also be helpful. >> >> When the PHP Group was mentioned I went hunting for details. I found a list >> of names at the top of https://www.php.net/credits.php but nothing covering >> what their role or authority is. > > > Their “role and authority” is copyright ownership of the “code, text, PHP logo, and graphical elements” of the PHP website. https://www.php.net/copyright.php
Clarification: I didn’t mean to imply just the PHP website. I meant the entire part of the PHP code base that is covered by the PHP license. https://github.com/php/php-src/blob/master/LICENSE Cheers, Ben
  106413
August 7, 2019 14:14 zeev@php.net (Zeev Suraski)
On Wed, Aug 7, 2019 at 4:56 PM Dan Ackroyd <Danack@basereality.com> wrote:

> On Wed, 7 Aug 2019 at 09:45, Peter Kokot <peterkokot@gmail.com> wrote: > > > > Yes, last time I was asking this, there was a clarification that > > certain people from the group internals can veto particular RFC. > > Please could you point to where this alleged rule has ever been > written down or agreed to? >
There's indeed no such rule that any individuals have a veto power.
> Although certain people may have claimed this is a rule, it's never > been agreed afaik. >
I'm not aware of anybody who ever claimed that such a rule existed, either. If people are alluding to me - then I don't claim I can veto anything; I think it's also clear from what I think about the short tags deprecation RFC that *if* I had veto power, that would be an instance where I'd use it. The reason we went for V2 aren't because of a veto, but because of issues in the previous RFC. With that said - the source code of PHP is copyrighted by the PHP Group - and it's a fact that is mentioned at the top of every PHP source file. The PHP Group is mostly inactive, and will likely stay this way, but under some extreme situations - it might choose to act (if ever - probably primarily around things that have to do with process). I think when we adopt a Code of Conduct one of the things we need to
> make explicit is that "claiming authority that is not codified" is > explicitly a thing that will not be allowed in internals discussions > as it seems to keep happening and results in a lot of confusion, and > frustration. >
The more accurate word here is 'if', rather than 'when'. But I don't think there's a need to wait for a CoC on this one - it should be clear that no individual has veto powers, but it should be also clear that not everything is up for a vote. Zeev
  106415
August 7, 2019 16:45 peterkokot@gmail.com (Peter Kokot)
On Wed, 7 Aug 2019 at 16:14, Zeev Suraski <zeev@php.net> wrote:
> > > > On Wed, Aug 7, 2019 at 4:56 PM Dan Ackroyd <Danack@basereality.com> wrote: >> >> On Wed, 7 Aug 2019 at 09:45, Peter Kokot <peterkokot@gmail.com> wrote: >> > >> > Yes, last time I was asking this, there was a clarification that >> > certain people from the group internals can veto particular RFC. >> >> Please could you point to where this alleged rule has ever been >> written down or agreed to? > > > There's indeed no such rule that any individuals have a veto power. > >> >> Although certain people may have claimed this is a rule, it's never >> been agreed afaik. > > > I'm not aware of anybody who ever claimed that such a rule existed, either. If people are alluding to me - then I don't claim I can veto anything; I think it's also clear from what I think about the short tags deprecation RFC that if I had veto power, that would be an instance where I'd use it. The reason we went for V2 aren't because of a veto, but because of issues in the previous RFC. > > With that said - the source code of PHP is copyrighted by the PHP Group - and it's a fact that is mentioned at the top of every PHP source file. The PHP Group is mostly inactive, and will likely stay this way, but under some extreme situations - it might choose to act (if ever - probably primarily around things that have to do with process). > >> I think when we adopt a Code of Conduct one of the things we need to >> make explicit is that "claiming authority that is not codified" is >> explicitly a thing that will not be allowed in internals discussions >> as it seems to keep happening and results in a lot of confusion, and >> frustration. > > > The more accurate word here is 'if', rather than 'when'. But I don't think there's a need to wait for a CoC on this one - it should be clear that no individual has veto powers, but it should be also clear that not everything is up for a vote. > > Zeev >
Veto has been mentioned here https://externals.io/message/105201#105558 I'm not having any issues with veto being used here or not on a previous RFC from people that are in the internals since day 1. I think we should respect that they have issues with proposals coming up in recent years, but hopefully group will also understand us - users and new contributors a bit that we just want to have a bit of cleanup of legacy things here and there :) Thanks and have a nice day. -- Peter Kokot
  106416
August 7, 2019 16:56 chasepeeler@gmail.com (Chase Peeler)
On Wed, Aug 7, 2019 at 12:45 PM Peter Kokot <peterkokot@gmail.com> wrote:

> On Wed, 7 Aug 2019 at 16:14, Zeev Suraski <zeev@php.net> wrote: > > > > > > > > On Wed, Aug 7, 2019 at 4:56 PM Dan Ackroyd <Danack@basereality.com> > wrote: > >> > >> On Wed, 7 Aug 2019 at 09:45, Peter Kokot <peterkokot@gmail.com> wrote: > >> > > >> > Yes, last time I was asking this, there was a clarification that > >> > certain people from the group internals can veto particular RFC. > >> > >> Please could you point to where this alleged rule has ever been > >> written down or agreed to? > > > > > > There's indeed no such rule that any individuals have a veto power. > > > >> > >> Although certain people may have claimed this is a rule, it's never > >> been agreed afaik. > > > > > > I'm not aware of anybody who ever claimed that such a rule existed, > either. If people are alluding to me - then I don't claim I can veto > anything; I think it's also clear from what I think about the short tags > deprecation RFC that if I had veto power, that would be an instance where > I'd use it. The reason we went for V2 aren't because of a veto, but > because of issues in the previous RFC. > > > > With that said - the source code of PHP is copyrighted by the PHP Group > - and it's a fact that is mentioned at the top of every PHP source file. > The PHP Group is mostly inactive, and will likely stay this way, but under > some extreme situations - it might choose to act (if ever - probably > primarily around things that have to do with process). > > > >> I think when we adopt a Code of Conduct one of the things we need to > >> make explicit is that "claiming authority that is not codified" is > >> explicitly a thing that will not be allowed in internals discussions > >> as it seems to keep happening and results in a lot of confusion, and > >> frustration. > > > > > > The more accurate word here is 'if', rather than 'when'. But I don't > think there's a need to wait for a CoC on this one - it should be clear > that no individual has veto powers, but it should be also clear that not > everything is up for a vote. > > > > Zeev > > > > Veto has been mentioned here > https://externals.io/message/105201#105558 > > I'm not having any issues with veto being used here or not on a > previous RFC from people that are in the internals since day 1. I > think we should respect that they have issues with proposals coming up > in recent years, but hopefully group will also understand us - users > and new contributors a bit that we just want to have a bit of cleanup > of legacy things here and there :) > > Thanks and have a nice day. > -- > Peter Kokot > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > What powers are available, and to whom they are available, is probably something that should be moved to another thread. We currently have at
least three different discussions going on in this thread: 1.) The RFC itself 2.) Default handling of the ini setting 3.) Whether certain people can veto RFCs. To address Andrey's initial concern, which is currently leading to him not voting: Nobody is vetoing anything. Due to both the procedural issues (the way the voting was structured with two options) as well as the severity of the issues raised after the voting, another RFC was proposed that supersedes the original RFC. The procedural issues alone were enough to warrant another vote on an RFC that had fixed those issues. This means that, for all intents and purposes, the first RFC never existed. If the current RFC passes, then it will be implemented as proposed. If it fails, then treatment of short tags will remain as it currently is. I hope you will reconsider your decision to not vote on this new RFC. I understand your concerns. As someone that didn't like the outcome of the first vote either, I also didn't feel that a revote just because a lot of people decided to speak up after the fact was the correct course of action. I don't think that is what is happening here, though. -- Chase Peeler chasepeeler@gmail.com
  106417
August 7, 2019 17:00 peterkokot@gmail.com (Peter Kokot)
Hello.

On Wed, 7 Aug 2019 at 18:56, Chase Peeler <chasepeeler@gmail.com> wrote:
> > > > On Wed, Aug 7, 2019 at 12:45 PM Peter Kokot <peterkokot@gmail.com> wrote: >> >> On Wed, 7 Aug 2019 at 16:14, Zeev Suraski <zeev@php.net> wrote: >> > >> > >> > >> > On Wed, Aug 7, 2019 at 4:56 PM Dan Ackroyd <Danack@basereality.com> wrote: >> >> >> >> On Wed, 7 Aug 2019 at 09:45, Peter Kokot <peterkokot@gmail.com> wrote: >> >> > >> >> > Yes, last time I was asking this, there was a clarification that >> >> > certain people from the group internals can veto particular RFC. >> >> >> >> Please could you point to where this alleged rule has ever been >> >> written down or agreed to? >> > >> > >> > There's indeed no such rule that any individuals have a veto power. >> > >> >> >> >> Although certain people may have claimed this is a rule, it's never >> >> been agreed afaik. >> > >> > >> > I'm not aware of anybody who ever claimed that such a rule existed, either. If people are alluding to me - then I don't claim I can veto anything; I think it's also clear from what I think about the short tags deprecation RFC that if I had veto power, that would be an instance where I'd use it. The reason we went for V2 aren't because of a veto, but because of issues in the previous RFC. >> > >> > With that said - the source code of PHP is copyrighted by the PHP Group - and it's a fact that is mentioned at the top of every PHP source file. The PHP Group is mostly inactive, and will likely stay this way, but under some extreme situations - it might choose to act (if ever - probably primarily around things that have to do with process). >> > >> >> I think when we adopt a Code of Conduct one of the things we need to >> >> make explicit is that "claiming authority that is not codified" is >> >> explicitly a thing that will not be allowed in internals discussions >> >> as it seems to keep happening and results in a lot of confusion, and >> >> frustration. >> > >> > >> > The more accurate word here is 'if', rather than 'when'. But I don't think there's a need to wait for a CoC on this one - it should be clear that no individual has veto powers, but it should be also clear that not everything is up for a vote. >> > >> > Zeev >> > >> >> Veto has been mentioned here >> https://externals.io/message/105201#105558 >> >> I'm not having any issues with veto being used here or not on a >> previous RFC from people that are in the internals since day 1. I >> think we should respect that they have issues with proposals coming up >> in recent years, but hopefully group will also understand us - users >> and new contributors a bit that we just want to have a bit of cleanup >> of legacy things here and there :) >> >> Thanks and have a nice day. >> -- >> Peter Kokot >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> > What powers are available, and to whom they are available, is probably something that should be moved to another thread. We currently have at least three different discussions going on in this thread: > 1.) The RFC itself > 2.) Default handling of the ini setting > 3.) Whether certain people can veto RFCs. > > To address Andrey's initial concern, which is currently leading to him not voting: > > Nobody is vetoing anything. Due to both the procedural issues (the way the voting was structured with two options) as well as the severity of the issues raised after the voting, another RFC was proposed that supersedes the original RFC. The procedural issues alone were enough to warrant another vote on an RFC that had fixed those issues. This means that, for all intents and purposes, the first RFC never existed. If the current RFC passes, then it will be implemented as proposed. If it fails, then treatment of short tags will remain as it currently is. > > I hope you will reconsider your decision to not vote on this new RFC. I understand your concerns. As someone that didn't like the outcome of the first vote either, I also didn't feel that a revote just because a lot of people decided to speak up after the fact was the correct course of action. I don't think that is what is happening here, though. > > -- > Chase Peeler > chasepeeler@gmail.com
Just to be more clear here. If the RFC fails then the short opening tags will stay in PHP for ever. I'm not sure what will change in 5 or 10 years so much so considering the feedback I think we should then leave them in for ever and enable them by default everywhere and have two PHP opening tags. Yes, this is what happens when there is no plan from key people involved here. -- Peter Kokot
  106418
August 7, 2019 17:03 chasepeeler@gmail.com (Chase Peeler)
On Wed, Aug 7, 2019 at 1:00 PM Peter Kokot <peterkokot@gmail.com> wrote:

> Hello. > > On Wed, 7 Aug 2019 at 18:56, Chase Peeler <chasepeeler@gmail.com> wrote: > > > > > > > > On Wed, Aug 7, 2019 at 12:45 PM Peter Kokot <peterkokot@gmail.com> > wrote: > >> > >> On Wed, 7 Aug 2019 at 16:14, Zeev Suraski <zeev@php.net> wrote: > >> > > >> > > >> > > >> > On Wed, Aug 7, 2019 at 4:56 PM Dan Ackroyd <Danack@basereality.com> > wrote: > >> >> > >> >> On Wed, 7 Aug 2019 at 09:45, Peter Kokot <peterkokot@gmail.com> > wrote: > >> >> > > >> >> > Yes, last time I was asking this, there was a clarification that > >> >> > certain people from the group internals can veto particular RFC. > >> >> > >> >> Please could you point to where this alleged rule has ever been > >> >> written down or agreed to? > >> > > >> > > >> > There's indeed no such rule that any individuals have a veto power. > >> > > >> >> > >> >> Although certain people may have claimed this is a rule, it's never > >> >> been agreed afaik. > >> > > >> > > >> > I'm not aware of anybody who ever claimed that such a rule existed, > either. If people are alluding to me - then I don't claim I can veto > anything; I think it's also clear from what I think about the short tags > deprecation RFC that if I had veto power, that would be an instance where > I'd use it. The reason we went for V2 aren't because of a veto, but > because of issues in the previous RFC. > >> > > >> > With that said - the source code of PHP is copyrighted by the PHP > Group - and it's a fact that is mentioned at the top of every PHP source > file. The PHP Group is mostly inactive, and will likely stay this way, but > under some extreme situations - it might choose to act (if ever - probably > primarily around things that have to do with process). > >> > > >> >> I think when we adopt a Code of Conduct one of the things we need to > >> >> make explicit is that "claiming authority that is not codified" is > >> >> explicitly a thing that will not be allowed in internals discussions > >> >> as it seems to keep happening and results in a lot of confusion, and > >> >> frustration. > >> > > >> > > >> > The more accurate word here is 'if', rather than 'when'. But I don't > think there's a need to wait for a CoC on this one - it should be clear > that no individual has veto powers, but it should be also clear that not > everything is up for a vote. > >> > > >> > Zeev > >> > > >> > >> Veto has been mentioned here > >> https://externals.io/message/105201#105558 > >> > >> I'm not having any issues with veto being used here or not on a > >> previous RFC from people that are in the internals since day 1. I > >> think we should respect that they have issues with proposals coming up > >> in recent years, but hopefully group will also understand us - users > >> and new contributors a bit that we just want to have a bit of cleanup > >> of legacy things here and there :) > >> > >> Thanks and have a nice day. > >> -- > >> Peter Kokot > >> > >> -- > >> PHP Internals - PHP Runtime Development Mailing List > >> To unsubscribe, visit: http://www.php.net/unsub.php > >> > > What powers are available, and to whom they are available, is probably > something that should be moved to another thread. We currently have at > least three different discussions going on in this thread: > > 1.) The RFC itself > > 2.) Default handling of the ini setting > > 3.) Whether certain people can veto RFCs. > > > > To address Andrey's initial concern, which is currently leading to him > not voting: > > > > Nobody is vetoing anything. Due to both the procedural issues (the way > the voting was structured with two options) as well as the severity of the > issues raised after the voting, another RFC was proposed that supersedes > the original RFC. The procedural issues alone were enough to warrant > another vote on an RFC that had fixed those issues. This means that, for > all intents and purposes, the first RFC never existed. If the current RFC > passes, then it will be implemented as proposed. If it fails, then > treatment of short tags will remain as it currently is. > > > > I hope you will reconsider your decision to not vote on this new RFC. I > understand your concerns. As someone that didn't like the outcome of the > first vote either, I also didn't feel that a revote just because a lot of > people decided to speak up after the fact was the correct course of action. > I don't think that is what is happening here, though. > > > > -- > > Chase Peeler > > chasepeeler@gmail.com > > Just to be more clear here. If the RFC fails then the short opening > tags will stay in PHP for ever. I'm not sure what will change in 5 or > 10 years so much so considering the feedback I think we should then > leave them in for ever and enable them by default everywhere and have > two PHP opening tags. Yes, this is what happens when there is no plan > from key people involved here. > > And why is supporting two types of opening tags so bad that it justifies such a large BC break? Support for short tags has existed since PHP3. Can
you point to anything you've written or used that would have been better had short tags never existed?
> -- > Peter Kokot >
-- Chase Peeler chasepeeler@gmail.com
  106420
August 7, 2019 17:44 peterkokot@gmail.com (Peter Kokot)
Hello,

On Wed, 7 Aug 2019 at 19:03, Chase Peeler <chasepeeler@gmail.com> wrote:
> > > > On Wed, Aug 7, 2019 at 1:00 PM Peter Kokot <peterkokot@gmail.com> wrote: >> >> Hello. >> >> On Wed, 7 Aug 2019 at 18:56, Chase Peeler <chasepeeler@gmail.com> wrote: >> > >> > >> > >> > On Wed, Aug 7, 2019 at 12:45 PM Peter Kokot <peterkokot@gmail.com> wrote: >> >> >> >> On Wed, 7 Aug 2019 at 16:14, Zeev Suraski <zeev@php.net> wrote: >> >> > >> >> > >> >> > >> >> > On Wed, Aug 7, 2019 at 4:56 PM Dan Ackroyd <Danack@basereality.com> wrote: >> >> >> >> >> >> On Wed, 7 Aug 2019 at 09:45, Peter Kokot <peterkokot@gmail.com> wrote: >> >> >> > >> >> >> > Yes, last time I was asking this, there was a clarification that >> >> >> > certain people from the group internals can veto particular RFC. >> >> >> >> >> >> Please could you point to where this alleged rule has ever been >> >> >> written down or agreed to? >> >> > >> >> > >> >> > There's indeed no such rule that any individuals have a veto power. >> >> > >> >> >> >> >> >> Although certain people may have claimed this is a rule, it's never >> >> >> been agreed afaik. >> >> > >> >> > >> >> > I'm not aware of anybody who ever claimed that such a rule existed, either. If people are alluding to me - then I don't claim I can veto anything; I think it's also clear from what I think about the short tags deprecation RFC that if I had veto power, that would be an instance where I'd use it. The reason we went for V2 aren't because of a veto, but because of issues in the previous RFC. >> >> > >> >> > With that said - the source code of PHP is copyrighted by the PHP Group - and it's a fact that is mentioned at the top of every PHP source file. The PHP Group is mostly inactive, and will likely stay this way, but under some extreme situations - it might choose to act (if ever - probably primarily around things that have to do with process). >> >> > >> >> >> I think when we adopt a Code of Conduct one of the things we need to >> >> >> make explicit is that "claiming authority that is not codified" is >> >> >> explicitly a thing that will not be allowed in internals discussions >> >> >> as it seems to keep happening and results in a lot of confusion, and >> >> >> frustration. >> >> > >> >> > >> >> > The more accurate word here is 'if', rather than 'when'. But I don't think there's a need to wait for a CoC on this one - it should be clear that no individual has veto powers, but it should be also clear that not everything is up for a vote. >> >> > >> >> > Zeev >> >> > >> >> >> >> Veto has been mentioned here >> >> https://externals.io/message/105201#105558 >> >> >> >> I'm not having any issues with veto being used here or not on a >> >> previous RFC from people that are in the internals since day 1. I >> >> think we should respect that they have issues with proposals coming up >> >> in recent years, but hopefully group will also understand us - users >> >> and new contributors a bit that we just want to have a bit of cleanup >> >> of legacy things here and there :) >> >> >> >> Thanks and have a nice day. >> >> -- >> >> Peter Kokot >> >> >> >> -- >> >> PHP Internals - PHP Runtime Development Mailing List >> >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> >> > What powers are available, and to whom they are available, is probably something that should be moved to another thread. We currently have at least three different discussions going on in this thread: >> > 1.) The RFC itself >> > 2.) Default handling of the ini setting >> > 3.) Whether certain people can veto RFCs. >> > >> > To address Andrey's initial concern, which is currently leading to him not voting: >> > >> > Nobody is vetoing anything. Due to both the procedural issues (the way the voting was structured with two options) as well as the severity of the issues raised after the voting, another RFC was proposed that supersedes the original RFC. The procedural issues alone were enough to warrant another vote on an RFC that had fixed those issues. This means that, for all intents and purposes, the first RFC never existed. If the current RFC passes, then it will be implemented as proposed. If it fails, then treatment of short tags will remain as it currently is. >> > >> > I hope you will reconsider your decision to not vote on this new RFC. I understand your concerns. As someone that didn't like the outcome of the first vote either, I also didn't feel that a revote just because a lot of people decided to speak up after the fact was the correct course of action. I don't think that is what is happening here, though. >> > >> > -- >> > Chase Peeler >> > chasepeeler@gmail.com >> >> Just to be more clear here. If the RFC fails then the short opening >> tags will stay in PHP for ever. I'm not sure what will change in 5 or >> 10 years so much so considering the feedback I think we should then >> leave them in for ever and enable them by default everywhere and have >> two PHP opening tags. Yes, this is what happens when there is no plan >> from key people involved here. >> > And why is supporting two types of opening tags so bad that it justifies such a large BC break? Support for short tags has existed since PHP3. Can you point to anything you've written or used that would have been better had short tags never existed? > >> >> -- >> Peter Kokot > > > > -- > Chase Peeler > chasepeeler@gmail.com
Considering that you're in favor of keeping the short opening tag in PHP "forever" because you haven't added any kind of other solution either by now neither you see an issue with this... I think the worst situation for language is that there is an option to write non portable code with this unfortunate short tag. It won't work everywhere. So, this is already a reason for thinking forward (at least from the progress and consistency point of view): A - removing one of the two options, so it is simpler to write portable code without warning users? or B - making both options always available so code is portable everywhere. The A is a compromise to ditch that legacy code and upgrade it (in a major version like PHP 9 - this is 5+ years from now). Option B is a way into a stable solution and also gazillion other problems that arise with it. From nicely explained ones in the RFC, to the teaching two things, etc. With option B there will soon happen also something else. Why using a longer tag if code can be a bit "shorter" and simpler with a short opening tag then? You can imagine the impossibility of removing the long tag from PHP just like that in some decent time, where we will have realistic option to push it to production... (option C): Postponing things to PHP 10 is simple and easy way out here but I'm not sure what is the point in that. We will have the same discussion then. It is way too far away from my understanding. Something like this in short. -- Peter Kokot
  106421
August 7, 2019 19:05 markyr@gmail.com (Mark Randall)
On 07/08/2019 18:44, Peter Kokot wrote:
> I think the worst > situation for language is that there is an option to write non > portable code with this unfortunate short tag. It won't work > everywhere. So, this is already a reason for thinking forward (at > least from the progress and consistency point of view)
I feel it necessary to point out that non-portability due to INI settings applies to almost everything PHP does, and in and of itself should not be considered a major argument. PHP is, after all, built almost entirely on extensions. Those extensions can either be there, or not, enabled in the INI, or not. Do we consider code written containing functions from mysqli, gd or zip (just to name a few) to be non-portable because we can omit them from the INI (or just not install them). There are arguments for and against removal. IMO non-portability is not one of them. IMHO short tag removal has one major thing going for it, consistency, and by extension, predictability. That's it. Is that enough? I'm on the fence. Mark Randall
  106422
August 7, 2019 19:25 zeev@php.net (Zeev Suraski)
On Wed, Aug 7, 2019 at 8:45 PM Peter Kokot <peterkokot@gmail.com> wrote:

> Considering that you're in favor of keeping the short opening tag in > PHP "forever" because you haven't added any kind of other solution
> either by now neither you see an issue with this... I think the worst > situation for language is that there is an option to write non > portable code with this unfortunate short tag.
Peter, To put it simply - many of us simply don't see an issue if short tags are with us even at PHP 99, centuries after we're no longer around. We certainly don't see an issue if it sticks with us until PHP 10. In fact, it's not that we don't think it's an issue - we actually think that's a Good Thing if it stays, and a Bad Thing if it's removed. I did my best to illustrate why I think that is the case in my Counterargument ( https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags). I accept that you see things differently. However, please accept that we also see things differently and are entitled to our opinion just as much as you are entitled to yours. We simply fail to see an issue with short tags that comes even close for us to want to remove it. It's not even a close call. A zero gain and substantial pain associated with a deprecation should be an obvious choice. To quote Sara Golemon: "Frankly, I can't understand why anyone *does* want to drop it." (https://twitter.com/SaraMG/status/1158936328450576384) PHP always had a bias for downwards compatibility. We went out of our way to come up with creative ways to reinvent the brain of the language several times - while going through hoops to keep code behavior identical. We did not shy away from breaking compatibility when there was a very strong case - such as the OO model between PHP 4 and 5, the deprecation of magic quotes and the deprecation of safe mode - all painful migrations, but with a very, very strong case that goes well beyond "having more than one way of doing things" or "this creates the possibility of non-portable code". TBH, I expected folks who are joining the project to accept that, although I guess I was naive as this is clearly not happening (it's only implied in the 'rules', but not actually codified). Repeating what I said a couple of weeks ago - it seems we've now switched to the business of breaking things almost for the sake of breaking things, and it's really disheartening. Many of us think that removing short tags does *absolutely nothing* to improve the portability of PHP code. I'll go beyond that - the ability to create non-portable code should never be grounds by itself for deprecating a feature (it can be a contributing factor). There are endless elements that an app can use that can make it non portable. For example, should we be deprecating support for all databases other than SQLite? After all, they may not always be installed. Should we deprecate the SHM extension? People using it may be stuck if they ever try to deploy to Windows. What about deprecating disable_functions? It's a portability disaster that's just waiting to happen. And I barely even got started. Almost anything beyond pure PHP logic may not work in all environments, and it's absolutely fine. It also constitutes absolutely no grounds for starting to go around axing features. Thankfully, fact is, not all code has to be portable. The important thing is that those who want to write portable code will be able to do so - while not forcing everyone else to write portable code by enforcing the lowest common denominator. I think Chase alluded to the fact that there's substantial anecdotal evidence that the availability of short tags did not actually cause any trouble in the last 20 years. And when I say anecdotal evidence - I mean that some of the most popular applications on the Web (including the top 3 most popular ones) have been written in PHP, and there's a gigantic framework ecosystem around PHP. I realize that you think it's a problem that we have two opening tags for PHP - and a major one at that. It's entirely your right to do so and I wholeheartedly accept it. Similarly, please accept it that I, as well as many others, simply don't view this as a problem. And when one does not think there's a problem, one typically does not spend time finding solutions. FWIW, if for whatever reason I did think it was a problem - I think the updated V2 RFC would be the best way to solve it. But I don't. With all that said, I still think there may be a solution that can make mostly everyone happy, or at least not really unhappy. It may even include deprecating short tags (in a way) - but more importantly - overhauling much more important elements in PHP as well. I hope to bring it up for some initial brainstorming (not RFC level, just gauging response) tomorrow. Zeev
  106423
August 7, 2019 19:45 sergey@s-panteleev.ru (Sergey Panteleev)
Hi there!

Perhaps I missed and someone already suggested,
but didn't consider a compromise option:
just change the default value short_open_tag=false,
and DON'T removes the option from php.ini?

If someone uses short tags - ok, they will change
the default value to true and everything will be as before,
who won't change it - will enjoy the full syntax

—
Sincerely,
Sergey Panteleev
https://s-panteleev.ru
Phone: +7 (906) 634-79-37
Telegram: @saundefined
E-mail: sergey@s-panteleev.ru
On 7 Aug 2019, 22:25 +0300, Zeev Suraski <zeev@php.net>, wrote:
> On Wed, Aug 7, 2019 at 8:45 PM Peter Kokot <peterkokot@gmail.com> wrote: > > > Considering that you're in favor of keeping the short opening tag in > > > PHP "forever" because you haven't added any kind of other solution > > either by now neither you see an issue with this... I think the worst > > situation for language is that there is an option to write non > > portable code with this unfortunate short tag. > > > Peter, > > To put it simply - many of us simply don't see an issue if short tags are > with us even at PHP 99, centuries after we're no longer around. We > certainly don't see an issue if it sticks with us until PHP 10. > > In fact, it's not that we don't think it's an issue - we actually think > that's a Good Thing if it stays, and a Bad Thing if it's removed. > > I did my best to illustrate why I think that is the case in my > Counterargument ( > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags). I > accept that you see things differently. However, please accept that we > also see things differently and are entitled to our opinion just as much as > you are entitled to yours. We simply fail to see an issue with short tags > that comes even close for us to want to remove it. It's not even a close > call. A zero gain and substantial pain associated with a deprecation > should be an obvious choice. > > To quote Sara Golemon: > "Frankly, I can't understand why anyone *does* want to drop it." > (https://twitter.com/SaraMG/status/1158936328450576384) > > PHP always had a bias for downwards compatibility. We went out of our way > to come up with creative ways to reinvent the brain of the language several > times - while going through hoops to keep code behavior identical. We did > not shy away from breaking compatibility when there was a very strong case > - such as the OO model between PHP 4 and 5, the deprecation of magic quotes > and the deprecation of safe mode - all painful migrations, but with a very, > very strong case that goes well beyond "having more than one way of doing > things" or "this creates the possibility of non-portable code". TBH, I > expected folks who are joining the project to accept that, although I guess > I was naive as this is clearly not happening (it's only implied in the > 'rules', but not actually codified). > > Repeating what I said a couple of weeks ago - it seems we've now switched > to the business of breaking things almost for the sake of breaking things, > and it's really disheartening. > > Many of us think that removing short tags does *absolutely nothing* to > improve the portability of PHP code. > > I'll go beyond that - the ability to create non-portable code should never > be grounds by itself for deprecating a feature (it can be a contributing > factor). There are endless elements that an app can use that can make it > non portable. For example, should we be deprecating support for all > databases other than SQLite? After all, they may not always be installed. > Should we deprecate the SHM extension? People using it may be stuck if > they ever try to deploy to Windows. What about deprecating > disable_functions? It's a portability disaster that's just waiting to > happen. And I barely even got started. Almost anything beyond pure PHP > logic may not work in all environments, and it's absolutely fine. It also > constitutes absolutely no grounds for starting to go around axing features. > > Thankfully, fact is, not all code has to be portable. The important thing > is that those who want to write portable code will be able to do so - while > not forcing everyone else to write portable code by enforcing the lowest > common denominator. > I think Chase alluded to the fact that there's substantial anecdotal > evidence that the availability of short tags did not actually cause any > trouble in the last 20 years. And when I say anecdotal evidence - I mean > that some of the most popular applications on the Web (including the top 3 > most popular ones) have been written in PHP, and there's a gigantic > framework ecosystem around PHP. > > I realize that you think it's a problem that we have two opening tags for > PHP - and a major one at that. It's entirely your right to do so and I > wholeheartedly accept it. Similarly, please accept it that I, as well as > many others, simply don't view this as a problem. And when one does not > think there's a problem, one typically does not spend time finding > solutions. > > FWIW, if for whatever reason I did think it was a problem - I think the > updated V2 RFC would be the best way to solve it. But I don't. > > With all that said, I still think there may be a solution that can make > mostly everyone happy, or at least not really unhappy. It may even include > deprecating short tags (in a way) - but more importantly - overhauling much > more important elements in PHP as well. I hope to bring it up for some > initial brainstorming (not RFC level, just gauging response) tomorrow.. > > Zeev
  106424
August 7, 2019 19:55 markyr@gmail.com (Mark Randall)
On 07/08/2019 20:45, Sergey Panteleev wrote:
> Perhaps I missed and someone already suggested, > but didn't consider a compromise option: > just change the default value short_open_tag=false, > and DON'T removes the option from php.ini?
Without the other changes, this would lead to potentially dangerous code and data leakage. It's not really viable to simply change the default, or remove the option, without creating a significant security risk. Upgrading from one version to the next, without explicitly specifying the configuration in the INI during the upgrade (if previously omitted), would treat code which was previously explicitly specified as valid, as no longer valid, and would expose it to the world. Mark Randall
  106433
August 8, 2019 11:30 rowan.collins@gmail.com (Rowan Collins)
On Wed, 7 Aug 2019 at 20:45, Sergey Panteleev <sergey@s-panteleev.ru> wrote:

> Hi there! > > Perhaps I missed and someone already suggested, > but didn't consider a compromise option: > just change the default value short_open_tag=false, > and DON'T removes the option from php.ini? > > If someone uses short tags - ok, they will change > the default value to true and everything will be as before, > who won't change it - will enjoy the full syntax >
Defaulting it to "off" would risk leaking people's code if they didn't set it, but I suggested earlier that it could default to a new "error" mode (which could also be explicitly set): https://externals.io/message/106384#106408 Regards, -- Rowan Collins [IMSoP]
  106427
August 7, 2019 21:39 peterkokot@gmail.com (Peter Kokot)
On Wed, 7 Aug 2019 at 21:25, Zeev Suraski <zeev@php.net> wrote:
> > > > On Wed, Aug 7, 2019 at 8:45 PM Peter Kokot <peterkokot@gmail.com> wrote: >> >> Considering that you're in favor of keeping the short opening tag in >> >> PHP "forever" because you haven't added any kind of other solution >> either by now neither you see an issue with this... I think the worst >> situation for language is that there is an option to write non >> portable code with this unfortunate short tag. > > > Peter, > > To put it simply - many of us simply don't see an issue if short tags are with us even at PHP 99, centuries after we're no longer around. We certainly don't see an issue if it sticks with us until PHP 10. > > In fact, it's not that we don't think it's an issue - we actually think that's a Good Thing if it stays, and a Bad Thing if it's removed. > > I did my best to illustrate why I think that is the case in my Counterargument (https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags). I accept that you see things differently. However, please accept that we also see things differently and are entitled to our opinion just as much as you are entitled to yours. We simply fail to see an issue with short tags that comes even close for us to want to remove it. It's not even a close call. A zero gain and substantial pain associated with a deprecation should be an obvious choice. > > To quote Sara Golemon: > "Frankly, I can't understand why anyone *does* want to drop it." > (https://twitter.com/SaraMG/status/1158936328450576384) > > PHP always had a bias for downwards compatibility. We went out of our way to come up with creative ways to reinvent the brain of the language several times - while going through hoops to keep code behavior identical. We did not shy away from breaking compatibility when there was a very strong case - such as the OO model between PHP 4 and 5, the deprecation of magic quotes and the deprecation of safe mode - all painful migrations, but with a very, very strong case that goes well beyond "having more than one way of doing things" or "this creates the possibility of non-portable code". TBH, I expected folks who are joining the project to accept that, although I guess I was naive as this is clearly not happening (it's only implied in the 'rules', but not actually codified). > > Repeating what I said a couple of weeks ago - it seems we've now switched to the business of breaking things almost for the sake of breaking things, and it's really disheartening. > > Many of us think that removing short tags does absolutely nothing to improve the portability of PHP code. > > I'll go beyond that - the ability to create non-portable code should never be grounds by itself for deprecating a feature (it can be a contributing factor). There are endless elements that an app can use that can make it non portable. For example, should we be deprecating support for all databases other than SQLite? After all, they may not always be installed. Should we deprecate the SHM extension? People using it may be stuck if they ever try to deploy to Windows. What about deprecating disable_functions? It's a portability disaster that's just waiting to happen. And I barely even got started. Almost anything beyond pure PHP logic may not work in all environments, and it's absolutely fine. It also constitutes absolutely no grounds for starting to go around axing features. > > Thankfully, fact is, not all code has to be portable. The important thing is that those who want to write portable code will be able to do so - while not forcing everyone else to write portable code by enforcing the lowest common denominator. > I think Chase alluded to the fact that there's substantial anecdotal evidence that the availability of short tags did not actually cause any trouble in the last 20 years. And when I say anecdotal evidence - I mean that some of the most popular applications on the Web (including the top 3 most popular ones) have been written in PHP, and there's a gigantic framework ecosystem around PHP. > > I realize that you think it's a problem that we have two opening tags for PHP - and a major one at that. It's entirely your right to do so and I wholeheartedly accept it. Similarly, please accept it that I, as well as many others, simply don't view this as a problem. And when one does not think there's a problem, one typically does not spend time finding solutions. > > FWIW, if for whatever reason I did think it was a problem - I think the updated V2 RFC would be the best way to solve it. But I don't. > > With all that said, I still think there may be a solution that can make mostly everyone happy, or at least not really unhappy. It may even include deprecating short tags (in a way) - but more importantly - overhauling much more important elements in PHP as well. I hope to bring it up for some initial brainstorming (not RFC level, just gauging response) tomorrow. > > Zeev >
Thank you for such a detailed response. Ok, I understand then. Then next logical step here is - I would maybe want to use these awesome short tags also then. They are shorter, which I like, templates look a bit more decent and aligned and all that what some have pointed out... So, why not enabling these short tags everywhere then and suggesting in the PHP manual that they can be used again in PHP x.y version etc? This is from the contributors point of view somehow I think a logical step forward - someone who sees there is something semi-working and possibly could be working everywhere without BC break issues so they want to fix this functionality as it could be fixed. Enabling these tags back (or enabling them for the first time everywhere without option to be disabled) is also a good thing according to all this. Yes? Because otherwise, I think it is a bit broken functionality by design if it causes so much issues to be removed and at the same time many people want to have it in PHP forever here... -- Peter Kokot
  106428
August 7, 2019 22:38 zeev@php.net (Zeev Suraski)
On Thu, Aug 8, 2019 at 12:39 AM Peter Kokot <peterkokot@gmail.com> wrote:

> Thank you for such a detailed response. Ok, I understand then. Then > next logical step here is - I would maybe want to use these awesome > short tags also then.
No disrespect Peter, but I really don't think you understand (my position). I don't think there's anything awesome about short tags. I don't think there's anything evil about them either. They are what they are, what they have been for the last two decades. They didn't cause any damage to PHP, and they won't start causing damage to PHP in the future. Personally, I like the verbose version a lot more, I like the verbosity. I'm capable of holding that preference in my mind alongside realizing that others have a different preference. I'm not missionary about my tag preferences, and neither should you. So, why not enabling these short tags everywhere then and suggesting
> in the PHP manual that they can be used again in PHP x.y version etc? >
As much as it's an uncommon use case - I think making PHP inherently incompatible with XML is not a good idea. As I mentioned, personally I also prefer the verbosity as well as the free PHP publicity in every tag. But a more fundamental level, I really fail to see any good reason to be spending our brain cycles on this matter (yes, I realize that we're waaay too late, but better late than never). This is a non-issue, that we suddenly made into an issue, and now we need to discuss it, come up with pros and cons, debate them, write lengthy proposals and counterarguments - and for what? For dealing with a non-issue. Can we turn this issue back into the non-issue that it is? Zeev
  106429
August 7, 2019 22:52 peterkokot@gmail.com (Peter Kokot)
On Thu, 8 Aug 2019 at 00:38, Zeev Suraski <zeev@php.net> wrote:
> > > > On Thu, Aug 8, 2019 at 12:39 AM Peter Kokot <peterkokot@gmail.com> wrote: >> >> Thank you for such a detailed response. Ok, I understand then. Then >> next logical step here is - I would maybe want to use these awesome >> short tags also then. > > > No disrespect Peter, but I really don't think you understand (my position). > > I don't think there's anything awesome about short tags. I don't think there's anything evil about them either. They are what they are, what they have been for the last two decades. They didn't cause any damage to PHP, and they won't start causing damage to PHP in the future. > Personally, I like the verbose version a lot more, I like the verbosity. I'm capable of holding that preference in my mind alongside realizing that others have a different preference. I'm not missionary about my tag preferences, and neither should you. > > >> So, why not enabling these short tags everywhere then and suggesting >> in the PHP manual that they can be used again in PHP x.y version etc? > > > As much as it's an uncommon use case - I think making PHP inherently incompatible with XML is not a good idea. As I mentioned, personally I also prefer the verbosity as well as the free PHP publicity in every tag. > > But a more fundamental level, I really fail to see any good reason to be spending our brain cycles on this matter (yes, I realize that we're waaay too late, but better late than never). > This is a non-issue, that we suddenly made into an issue, and now we need to discuss it, come up with pros and cons, debate them, write lengthy proposals and counterarguments - and for what? For dealing with a non-issue. > Can we turn this issue back into the non-issue that it is? > > Zeev
I can do that. I just wanted to get some more possible explanations, because there isn't any guideline why these tags are (still) in PHP and why someone would want to use them (because this is the case actually). Now, I think we all understand better here. No. 1 reason they are (still) there is the legacy code support - understandable. They in its core essence shouldn't be used and are discouraged further on as manual suggests. Many languages would make these "obsolete" somehow (probably) I think but ok if they are meant to be in, so be it... And maybe also for the community out there to understand this entire issue better and the outcome of the RFC whatever it is when voting ends. Have a nice day forward... -- Peter Kokot
  106397
August 6, 2019 18:46 nikita.ppv@gmail.com (Nikita Popov)
On Tue, Aug 6, 2019 at 1:34 PM G. P. B. banyard@gmail.com> wrote:

> The voting for the "Deprecate short open tags, again" [1] RFC has begun. > It is expected to last two (2) weeks until 2019-08-20. > > A counter argument to this RFC is available at > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags > > Best regards > > George P. Banyard > > [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2 >
Side-note: Even if this RFC fails, we should probably still make it an error to use
  106398
August 6, 2019 19:16 zeev@zend.com (Zeev Suraski)
> On 6 Aug 2019, at 21:46, Nikita Popov ppv@gmail.com> wrote: > >> On Tue, Aug 6, 2019 at 1:34 PM G. P. B. banyard@gmail.com> wrote: >> >> The voting for the "Deprecate short open tags, again" [1] RFC has begun. >> It is expected to last two (2) weeks until 2019-08-20. >> >> A counter argument to this RFC is available at >> https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags >> >> Best regards >> >> George P. Banyard >> >> [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2 >> > > Side-note: Even if this RFC fails, we should probably still make it an > error to use may flip the default to off at some later point in time. The current > default being "on" despite their use being discouraged is half the trouble. >
That’s a good idea. I was genuinely surprised to learn that wasn’t already the case, although the actual impact of that is quite limited given the fact that virtually all common deployments come preconfigured with short tags set to off. Zeev
  106400
August 6, 2019 21:55 claude.pache@gmail.com (Claude Pache)
> Le 6 août 2019 à 20:46, Nikita Popov ppv@gmail.com> a écrit : > > On Tue, Aug 6, 2019 at 1:34 PM G. P. B. banyard@gmail.com> wrote: > >> The voting for the "Deprecate short open tags, again" [1] RFC has begun. >> It is expected to last two (2) weeks until 2019-08-20. >> >> A counter argument to this RFC is available at >> https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags >> >> Best regards >> >> George P. Banyard >> >> [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2 >> > > Side-note: Even if this RFC fails, we should probably still make it an > error to use may flip the default to off at some later point in time. The current > default being "on" despite their use being discouraged is half the trouble. > > Nikita
That would mean in particular that XML documents could no longer be preprocessed by PHP without boilerplate around its `` declaration. I doubt that this is a more acceptable breaking change than deprecating short_tags. —Claude
  106401
August 6, 2019 22:45 walterp@gmail.com (Walter Parker)
On Tue, Aug 6, 2019 at 2:55 PM Claude Pache pache@gmail.com> wrote:

> > > > Le 6 août 2019 à 20:46, Nikita Popov ppv@gmail.com> a écrit : > > > > On Tue, Aug 6, 2019 at 1:34 PM G. P. B. banyard@gmail.com> > wrote: > > > >> The voting for the "Deprecate short open tags, again" [1] RFC has begun. > >> It is expected to last two (2) weeks until 2019-08-20. > >> > >> A counter argument to this RFC is available at > >> https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags > >> > >> Best regards > >> > >> George P. Banyard > >> > >> [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2 > >> > > > > Side-note: Even if this RFC fails, we should probably still make it an > > error to use we > > may flip the default to off at some later point in time. The current > > default being "on" despite their use being discouraged is half the > trouble. > > > > Nikita > > > That would mean in particular that XML documents could no longer be > preprocessed by PHP without boilerplate around its `` declaration.. > I doubt that this is a more acceptable breaking change than deprecating > short_tags. > > —Claude > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Why would you want to use PHP's preprocessor for XML? Why not use the right tool for the job? Such as an XML processor that could
also do schema validation? PHP has XML processing packages. It has been a while since I did XML processing, but I don't remember the packages being all that difficult to use. Is this a mixing data and code into the same file problem? Like HTML files that have PHP embedded directly in the file? Or this about stuffing PHP inside of XML documents? Walter -- The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
  106404
August 7, 2019 08:11 nikita.ppv@gmail.com (Nikita Popov)
On Tue, Aug 6, 2019 at 11:55 PM Claude Pache pache@gmail.com> wrote:

> > > > Le 6 août 2019 à 20:46, Nikita Popov ppv@gmail.com> a écrit : > > > > On Tue, Aug 6, 2019 at 1:34 PM G. P. B. banyard@gmail.com> > wrote: > > > >> The voting for the "Deprecate short open tags, again" [1] RFC has begun. > >> It is expected to last two (2) weeks until 2019-08-20. > >> > >> A counter argument to this RFC is available at > >> https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags > >> > >> Best regards > >> > >> George P. Banyard > >> > >> [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2 > >> > > > > Side-note: Even if this RFC fails, we should probably still make it an > > error to use we > > may flip the default to off at some later point in time. The current > > default being "on" despite their use being discouraged is half the > trouble. > > > > Nikita > > > That would mean in particular that XML documents could no longer be > preprocessed by PHP without boilerplate around its `` declaration.. > I doubt that this is a more acceptable breaking change than deprecating > short_tags.
To clarify: What I had in mind is that use of in PHP code requires an explicit short_tags=Off right now, so the situation there shouldn't change, unless I'm missing something. The only motivation here is to allow us to change the default to short_tags=Off at some point in the future (say PHP 9), after enough time has passed where short_tags cannot be used by default, without explicitly being enabled. We can't just flip the default right now due to the usual code leaking concerns. Regards, Nikita
  106408
August 7, 2019 13:12 rowan.collins@gmail.com (Rowan Collins)
On 07/08/2019 09:11, Nikita Popov wrote:
> To clarify: What I had in mind is that use of only if short_tags is left at its default value (of On). If short_tags is > explicitly Off or explicitly On, everything works as usual. Embedding ?> in PHP code requires an explicit short_tags=Off right now, so the > situation there shouldn't change, unless I'm missing something.
Since it would behave differently, it wouldn't make sense to say that it defaulted to "On", but that actually leads to an interesting feature: add an "error" mode to that setting. So the options would be: - error: any use of "
  106419
August 7, 2019 17:13 nicolas.grekas+php@gmail.com (Nicolas Grekas)
Le mar. 6 août 2019 à 13:34, G. P. B. banyard@gmail.com> a écrit :

> The voting for the "Deprecate short open tags, again" [1] RFC has begun. > It is expected to last two (2) weeks until 2019-08-20. > > A counter argument to this RFC is available at > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags > > Best regards > > George P. Banyard > > [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2
The counter-arguments are a really nice addition to the process. Reading them made me think there is a big missing "pro" argument: perceived complexity of the engine. When there is no choice to make (short tags on/off, magic_quote on/off, etc), then there is only one thing to teach, one thing to learn, one thing to (not have to) agree on when deciding for some conventions, etc. When there are N binary options (and not all options are binary), there are 2^N things to teach, learn, etc. That's a major cost put on the community. Choices that were made years ago when PHP was not what it is today were certainly fine, but nowadays, this imposes significant a burden on everyone. Each option individually are maybe minor, but the 2^N becomes quickly big. I think we should make such things way simpler so that we can free the brains of many to do the next things that matter. I don't have a vote, but if I were I would vote "yes". Instead, I encourage "no"-voters to reconsider, and others to vote "yes" too :) Cheers, Nicolas
  106425
August 7, 2019 19:57 chasepeeler@gmail.com (Chase Peeler)
On Wed, Aug 7, 2019 at 1:14 PM Nicolas Grekas grekas+php@gmail.com>
wrote:

> Le mar. 6 août 2019 à 13:34, G. P. B. banyard@gmail.com> a écrit : > > > The voting for the "Deprecate short open tags, again" [1] RFC has begun.. > > It is expected to last two (2) weeks until 2019-08-20. > > > > A counter argument to this RFC is available at > > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags > > > > Best regards > > > > George P. Banyard > > > > [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2 > > > > The counter-arguments are a really nice addition to the process. > > Reading them made me think there is a big missing "pro" argument: perceived > complexity of the engine. > > When there is no choice to make (short tags on/off, magic_quote on/off, > etc), then there is only one thing to teach, one thing to learn, one thing > to (not have to) agree on when deciding for some conventions, etc. > > When there are N binary options (and not all options are binary), there are > 2^N things to teach, learn, etc. > > In this case, claiming a slippery-slope is a logical fallacy. We aren't talking about opening it up so that we can add even more opening tags in
the future. The odds are pretty much zero that keeping short tags would lead to it in the future. We're talking about two possible ways to begin a block of PHP code. > That's a major cost put on the community. Choices that were made years ago > when PHP was not what it is today were certainly fine, but nowadays, this > imposes significant a burden on everyone. Each option individually are > maybe minor, but the 2^N becomes quickly big. I think we should make such > things way simpler so that we can free the brains of many to do the next > things that matter. > > I think the cost put on the community to fix existing instances of short tags is a MUCH higher burden than asking them know about the existence of
short tags should they encounter them one day. I'm in charge of maintaining a very large legacy code base. The majority of the legacy code is "leave it alone code" that is slowly getting re-written. The code is horrendous. Things have broken in the past from running PhpStorm's auto-formatting on a file. The effort required to update all of that code in order to upgrade would be so high that it's likely I would never get approval from my superiors to spend that much time on it.
> I don't have a vote, but if I were I would vote "yes". Instead, I encourage > "no"-voters to reconsider, and others to vote "yes" too :) > > Cheers, > Nicolas >
-- Chase Peeler chasepeeler@gmail.com
  106431
August 8, 2019 10:26 come@opensides.be (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Le mercredi 7 août 2019, 15:57:02 CEST Chase Peeler a écrit :
> Pretty much everyone (if not actually > everyone) that is against this RFC has stated that they don't actually use > short tags, and do not advocate that anyone else use them either.
This is what bugs me, the counter argument page from Zeev states «I never use short tags in any PHP code that I write, and as far as I recall - I never have. », and at the same time «put hundreds of thousands of people through additional pain when upgrading.» Is there any data that support the theory that hundreds of thousands of people use short tags? Did anyone in this discussion stated that he was using them?
  106432
August 8, 2019 10:51 r@roze.lv ("Reinis Rozitis")
> -----Original Message----- > From: Côme Chilliet [mailto:come@opensides.be] > > This is what bugs me, the counter argument page from Zeev states «I never > use short tags in any PHP code that I write, and as far as I recall - I never > have. », and at the same time «put hundreds of thousands of people > through additional pain when upgrading.»
Why does/should it bug you? The statements aren't contradictory. There are (must be) a lot of features which a particular language developer might not use (or even find ridiculous) himself personally but those still have been implemented historically or for future use for other users/clients etc.
> Did anyone in this discussion stated that he was using them?
Yes. rr
  106434
August 8, 2019 12:16 brendt@stitcher.io (Brent)
I asked similar questions on Twitter, where Zeev replied the following: https://mobile.twitter.com/zeevs/status/1158688885658046464

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

Kind regards
Brent
On 8 Aug 2019, 12:27 +0200, Côme Chilliet <come@opensides.be>, wrote:
> Le mercredi 7 août 2019, 15:57:02 CEST Chase Peeler a écrit : > > Pretty much everyone (if not actually > > everyone) that is against this RFC has stated that they don't actually use > > short tags, and do not advocate that anyone else use them either. > > This is what bugs me, the counter argument page from Zeev states «I never use short tags in any PHP code that I write, and as far as I recall - I never have. », > and at the same time «put hundreds of thousands of people through additional pain when upgrading.» > > Is there any data that support the theory that hundreds of thousands of people use short tags? > > Did anyone in this discussion stated that he was using them? > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
  106435
August 8, 2019 12:41 r@roze.lv ("Reinis Rozitis")
> -----Original Message----- > From: Brent [mailto:brendt@stitcher.io] > > > It feels like much of the counter arguments are based on guesses without any > real data to point to.
It goes both ways - the argument for removal states "This means that their use is not possible in portable code, because the code author does not necessarily have the necessary control over the configuration". What is the number/statistics of developers which have written a portable (in their mind) code (which means NOT using short tags) just to find out that the code/application doesn't work because those are disabled? Is there real data for that? rr
  106436
August 8, 2019 12:54 rowan.collins@gmail.com (Rowan Collins)
On 8 August 2019 13:16:56 BST, Brent <brendt@stitcher.io> wrote:
>I asked similar questions on Twitter, where Zeev replied the >following: > >> With an estimated number of PHP developers >> at 10M, 1% is 100K. Whether I know this for >> sure is not at all the point - it's never how we >> take decisions. The question is whether it's >> reasonable or not. And my guess is that a lot >> more than 1% uses short tags. > >It feels like much of the counter arguments are based on guesses >without any real data to point to.
You can take that both ways though: the argument that short tags should be removed is based on the same guesses. I understand Zeev's frustration in being asked to provide the proof when his position is that we shouldn't be spending any time on the issue at all. It should be up to those who think a change is necessary to demonstrate both the harm of the status quo (e.g. real-world cases of code exposure), and that it outweighs the cost of change (e.g. how many users will need to change working code). It would be different if we were choosing between two versions of some feature, but no-change should always have a starting advantage over change, which is why we require a super-majority in primary RFC votes. Regards, -- Rowan Collins [IMSoP]
  106437
August 8, 2019 13:35 zeev@php.net (Zeev Suraski)
On Thu, Aug 8, 2019 at 3:17 PM Brent <brendt@stitcher.io> wrote:

> I asked similar questions on Twitter, where Zeev replied the following: > https://mobile.twitter.com/zeevs/status/1158688885658046464
I want to add a bit of color to this tweet: - Estimated # of developers using PHP is at around 10M. This is based on some extrapolation from an EDS report from ~8 years ago that estimated that number at >6M, and growth rates we've seen beforehand. - Anecdotally, I've seen it used many times in non-distributable code over the years - a lot more frequently than once per 100 users. - Even if just 1% of the userbase uses short tags, that's ~100K. We can call this one a guess, but I'd say it's an educated guess that there's well above 1% of the PHP userbase that uses short tags. It feels like much of the counter arguments are based on guesses without
> any real data to point to.
I wouldn't say they're guesses, but extrapolations - for instance, the fact I'm aware of many PHP frameworks and apps, and am not aware of any single one that allows short tags - makes me feel fairly comfortable to make the statement that "virtually all frameworks and apps designed for public consumption disallow short tags". I can't preclude the possibility that the fact that all of the apps and frameworks I'm aware of don't allow short tags is a remarkable coincidence - or that there are countless ones I'm not aware of that do allow short tags - but I think that my theory is a lot more plausible. Zeev
  106438
August 8, 2019 14:16 chasepeeler@gmail.com (Chase Peeler)
On Thu, Aug 8, 2019 at 9:35 AM Zeev Suraski <zeev@php.net> wrote:

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

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

> Hello, > Thanks for sharing your stories about issues. Maybe we should start > also thinking about the impact on the language attractiveness to pick > it when starting a new web project since the core people can't come to > conclusions how to make the language more consistent on the long run > (PHP 9 etc)... With more and more ambiguities, inconsistencies, > lockups, and dead ends behind the language there is probably also a > bit of a factor to consider that it lowers this attractiveness. > Meaning less people will think of adopting it (with all the things > combined - short tags, that and that inconsistency not being removed > from PHP due to major disastrous BC break there and there). So, the > damage is also on the long run with more and more locks and dead ends > not being able to be fixed and cleaned. > > > -- > Peter Kokot > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Hello.
Peter above put my thoughts perfectly. BC is great, but you need to pull the cord at some point. And the whole short tag back and forth, with deprecation warning and stuff, has been around for last half a decade. It is time to accept that it needs to go and there should be no runtime dependent switch for this. Valid PHP tags are `godjuks@gmail.com Skype: psihius Telegram: @psihius https://t.me/psihius
  106442
August 8, 2019 15:42 rowan.collins@gmail.com (Rowan Collins)
On Thu, 8 Aug 2019 at 16:18, Arvids Godjuks godjuks@gmail.com>
wrote:

> BC is great, but you need to pull the cord at some point. And the whole > short tag back and forth, with deprecation warning and stuff, has been > around for last half a decade. It is time to accept that it needs to go >
That's like saying from now on we should mandate PSR-2 indenting style in the compiler, to stop people arguing about code formatting. Just because people keep saying something, doesn't make it right.
> If the old guard starts to push back as much as I have seen here, we are > going to lose momentum as a community and have people not willing to work > on PHP as much. >
I feel like the opposite: if people volunteering their time find that all their energy is spent on pointless arguments about removing working features, and none of it is spent on actually innovating the language, they'll spend it somewhere else.
> Long story short - indecision is not an option.
Here's a decision for you then: short tags are fine how they are, and we can stop wasting energy talking about them and get on with doing something that actually benefits the language. That's not indecision, that's a concrete position we could take to prioritise our efforts on something more productive. The previous RFC has
> passed. Everyone involved, I hope, understands that yes, there will be > stuff going wrong for some users who are careless and/or ignorant and live > under a rock. Can we really do anything about that?
Yes. Yes, we can. We can do what's proposed in the v2 RFC, or we can reverse our decision. An RFC passing isn't a pact with the devil.
> Let's look into the future, use a reasonable amount of caution and/or > deprecation notice periods, but please stop trying to block features >
What is the feature being blocked if we leave short tags in PHP? If such a feature existed, I would understand your frustration - but if it did, the RFC could make the case for why adding that new feature was worth the pain caused by removing the old feature. Since there is no such feature, there is no such justification in the RFC, which is why it's so controversial. Regards, -- Rowan Collins [IMSoP]
  106443
August 8, 2019 15:42 chasepeeler@gmail.com (Chase Peeler)
On Thu, Aug 8, 2019 at 11:18 AM Arvids Godjuks godjuks@gmail.com>
wrote:

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

> > > On Thu, Aug 8, 2019 at 11:18 AM Arvids Godjuks godjuks@gmail.com> > wrote: > >> чт, 8 авг. 2019 г. в 16:42, Peter Kokot <peterkokot@gmail.com>: >> >>> Hello, >>> Thanks for sharing your stories about issues. Maybe we should start >>> also thinking about the impact on the language attractiveness to pick >>> it when starting a new web project since the core people can't come to >>> conclusions how to make the language more consistent on the long run >>> (PHP 9 etc)... With more and more ambiguities, inconsistencies, >>> lockups, and dead ends behind the language there is probably also a >>> bit of a factor to consider that it lowers this attractiveness. >>> Meaning less people will think of adopting it (with all the things >>> combined - short tags, that and that inconsistency not being removed >>> from PHP due to major disastrous BC break there and there). So, the >>> damage is also on the long run with more and more locks and dead ends >>> not being able to be fixed and cleaned. >>> >>> >>> -- >>> Peter Kokot >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> >> Hello. >> >> Peter above put my thoughts perfectly. >> >> BC is great, but you need to pull the cord at some point. And the whole >> short tag back and forth, with deprecation warning and stuff, has been >> around for last half a decade. It is time to accept that it needs to go and >> there should be no runtime dependent switch for this. Valid PHP tags are >> `> I really liked how language picked up the cleanup pace in the last few >> years and it needs it. I finally see genuine interest in people to actually >> either come back or pick it up instead of JavaScript (NodeJS) and other >> fancy new shiny stuff. And a lot of it is because of the cleanup efforts >> and WTF?! removal, the language having the option to be stricter (I was not >> a fan of strict mode when it was coming up - now I don't use anything else >> - it is AWESOME). >> If the old guard starts to push back as much as I have seen here, we are >> going to lose momentum as a community and have people not willing to work >> on PHP as much. I mean anyone who has been on this list for more than 10 >> years should remember how it was in 5.0-5.4 days - slow, painful and >> somewhat unfriendly, until a few major contributors kind'a muddled though >> and pushed a few major changes that allowed the momentum to build up and >> somewhat break the stalemate (and it did help that HHVM reared it's head >> and had stroked a few egos the wrong way). I guess the curve repeats >> itself, but we should make an effort to curb it and not revert back to "BC, >> BC, BC!!!!" holding everything up. >> >> Wait, how could positive progress have been made while short tags still > existed? > > >> Reality is, a lot of those "non-tech company" examples people give here >> has nothing to do with language evolution. Yes, they are users, but we are >> not responsible for the code they write, for the way they configure their >> web servers and the way they can run a PHP4 server past 10 years and still >> have no clue, because nobody cares or "it works, it makes money, no need to >> invest". I would say that most of us on this list, if not everyone, are >> smart enough to run/leave/not work for companies like that, so we are >> somewhat shielded from that ignorance and just forget how bad it can be. >> >> Long story short - indecision is not an option. The previous RFC has >> passed. Everyone involved, I hope, understands that yes, there will be >> stuff going wrong for some users who are careless and/or ignorant and live >> under a rock. Can we really do anything about that? I would say no unless >> we freeze the language and do nothing. I mean I have exposed my PHP code >> during server setup by just forgetting to do `systemctl reload nginx`, >> hitting the URL and getting my `index.php` on the screen more times than I >> care to confess to. >> > You're in the "all or nothing" logical fallacy. You are acting as if being > against the removal of short tags is the same as being against any BC break > at all. As we've said MANY times, BC breaks aren't the issue. THIS > PARTICULAR BC BREAK IS THE ISSUE. It provides little to no positives to the > users and does very little, if anything, to improve the language. At the > same time it WILL lead to a very big barrier in terms of the ability to > upgrade for a large number of users. >
The RFC's both covered the fact that there is no good way to deprecate and remove short tags cleanly. Whatever road you take - it is going to result in issues for some users. The crux here is not the tags themselves per-se, but the engine level switch that changes the functionality of how the code is parsed. I mean if push comes to shove and people really really really do not want to remove `> > >> Let's look into the future, use a reasonable amount of caution and/or >> deprecation notice periods, but please stop trying to block features >> "because stupid users". You give them the most secure software you can >> write, they go change settings on their own and get p0wned/defaced/hacked >> anyway even when you tell them not to do it and that y'r refusing to work >> on their project because of decisions they make. >> >> Actually, most BC breaks, including this one, seem to be focused on > preventing issues from "stupid users." We're saying that short tags are bad > because of reasons. We can't trust users to not use short tags as long as > they exist, so we must force them to stop using them, no matter how painful > that might be. That's actually an OK thing to do if the reasons for doing > so justify it. I have yet to see the justification. All I've seen is people > attempt to mitigate the cost of the break, or, say the cost doesn't really > matter. >
Because it is a runtime switch that affects how the engine works. It has been agreed years ago that they need to go like `register_globals` and a few others have been removed with time. This is the same category. It is language and engine cleanup. -- Arvīds Godjuks +371 26 851 664 arvids.godjuks@gmail.com Skype: psihius Telegram: @psihius https://t.me/psihius
  106441
August 8, 2019 15:26 chasepeeler@gmail.com (Chase Peeler)
On Thu, Aug 8, 2019 at 10:42 AM Peter Kokot <peterkokot@gmail.com> wrote:

> Hello, > > On Thu, 8 Aug 2019 at 16:17, Chase Peeler <chasepeeler@gmail.com> wrote: > > > > On Thu, Aug 8, 2019 at 9:35 AM Zeev Suraski <zeev@php.net> wrote: > > > > > On Thu, Aug 8, 2019 at 3:17 PM Brent <brendt@stitcher.io> wrote: > > > > > > > I asked similar questions on Twitter, where Zeev replied the > following: > > > > https://mobile.twitter.com/zeevs/status/1158688885658046464 > > > > > > > > > I want to add a bit of color to this tweet: > > > - Estimated # of developers using PHP is at around 10M. This is based > on > > > some extrapolation from an EDS report from ~8 years ago that estimated > that > > > number at >6M, and growth rates we've seen beforehand. > > > - Anecdotally, I've seen it used many times in non-distributable code > over > > > the years - a lot more frequently than once per 100 users. > > > - Even if just 1% of the userbase uses short tags, that's ~100K. We > can > > > call this one a guess, but I'd say it's an educated guess that there's > well > > > above 1% of the PHP userbase that uses short tags. > > > > > > It feels like much of the counter arguments are based on guesses > without > > > > any real data to point to. > > > > > > > > > I wouldn't say they're guesses, but extrapolations - for instance, the > fact > > > I'm aware of many PHP frameworks and apps, and am not aware of any > single > > > one that allows short tags - makes me feel fairly comfortable to make > the > > > statement that "virtually all frameworks and apps designed for public > > > consumption disallow short tags". I can't preclude the possibility > that > > > the fact that all of the apps and frameworks I'm aware of don't allow > short > > > tags is a remarkable coincidence - or that there are countless ones > I'm not > > > aware of that do allow short tags - but I think that my theory is a lot > > > more plausible. > > > > > > I work on an internal application. Even though portability is not a > > concern for anything we write, we haven't used short tags since it was > > rumored they were going to be removed in PHP 6 many years ago. That being > > said, this application has been in development since 2003. There is a > large > > amount of legacy code written before I even started here, not to mention > > plenty of horrible code written after I did start in 2005 (this was my > > first job). As I mentioned in an email on this thread yesterday, most of > > our legacy code is "just leave it alone, it works" code. We are in the > > process of rewriting things, but, that takes time. We try and mess with > the > > legacy code as little as possible. Something as simple as auto formatting > > with PhpStorm has broken things in the past - so I don't trust an > automated > > tool to fix the short tags for me. Even if I'm the only person that has > > participated in this thread that has to maintain a codebase that consists > > of non-portable code with a large amount of short tags, that's still at > > least 1% of those that have participated in this thread, or one of its > > predecessors. > > > > Another thing to keep in mind is that most of the people writing and/or > > maintaining "non-portable" code probably don't work for a company in the > > software development industry. When I want to upgrade PHP, I have to > > convince our leadership of the value of me spending a couple of weeks > > fixing BC breaks. I have to show why that is more valuable than spending > > time on the development of new functionality. The more time required to > do > > an upgrade, the more likely it will get punted to a future date. > > > > I'm not against BC breaks in general - they are a necessary evil. > However, > > it's important that the negative impact of that break is far outweighed > by > > the positive value it brings. I'll leave it up to each of you to > determine > > how positive of an impact removing short tags would bring. I can promise > > you, though, that the negative impact would be VERY large. Just because > you > > don't personally have to maintain any code that uses short tags doesn't > > mean that there aren't other developers out there that do. Every BC break > > is going to lead to a subset of users that will decide to not upgrade as > a > > result. It will also lead to a subset of users that will decide to use a > > different technology (node, .NET, python, etc.) going forward. Many BC > > breaks are worth that risk. Is this one of them? > > > > Many people have talked about the potential impacts of keeping short > tags. > > I have yet to see anyone give an actual example where they have been > > negatively impacted by their existence. I've given you my personal story > of > > how removing them will negatively impact my company. I welcome anyone > that > > can provide an actual incident where the existence of short tags hurt > them, > > or, the continued existence is likely to have a large negative impact on > > them in the future. > > > > > > > Zeev > > > > > > > > > -- > > Chase Peeler > > chasepeeler@gmail.com > > Thanks for sharing your stories about issues. Maybe we should start > also thinking about the impact on the language attractiveness to pick > it when starting a new web project since the core people can't come to > conclusions how to make the language more consistent on the long run > (PHP 9 etc)... With more and more ambiguities, inconsistencies, > lockups, and dead ends behind the language there is probably also a > bit of a factor to consider that it lowers this attractiveness. > Meaning less people will think of adopting it (with all the things > combined - short tags, that and that inconsistency not being removed
from PHP due to major disastrous BC break there and there). So, the damage is also on the long run with more and more locks and dead ends
> not being able to be fixed and cleaned. > > Can you find me one person that has chosen to not use PHP because it supports two types of opening tags?
I'll make you a deal. If we can get rid of every other "inconsistency, ambiguity, lockup, and dead end" in the language, then I will come out in full support of removing short tags. Let's also get rid of every camelCase function and change it to underscore_case. That will help consistency. I'm personally willing to bet that more people are turned off by PHP's inconsistent function naming than the fact it allows multiple opening tags. I'll amend my offer. If PHP reaches a point where all core functions have a consistent naming format, I'll support removing short tags. We have to get rid of the old function names, though, otherwise people might get confused. Honestly, at this point you're just being a bit silly. No one has ever spoken out against BC breaks that have a positive impact on the language. Heck, if there isn't a negative impact to a BC break, I don't think anyone really cares, even if there isn't a positive one. There also isn't some slippery slope out there where if we allow short tags to remain we'll suddenly return to all out chaos where we don't continue to attempt to improve the language. "with all the things combined - short tags, that and that inconsistency not being removed" That reminds me of a baseball statistic. Hank Aaron and his brother Tommie combined to hit the most home runs among brothers: 768. Hank Aaron hit 755 of those. For those that don't follow baseball, only Barry Bonds has hit more home runs than Hank Aaron. Short tags are kind of like Tommie Aaron when it comes to the negative perceptions people have of the language. Getting rid of them really won't make that much of a difference.
> > -- > Peter Kokot >
-- Chase Peeler chasepeeler@gmail.com
  106445
August 8, 2019 15:56 robert@korulczyk.pl (Robert Korulczyk)
> Many people have talked about the potential impacts of keeping short tags. > I have yet to see anyone give an actual example where they have been > negatively impacted by their existence. I've given you my personal story of > how removing them will negatively impact my company. I welcome anyone that > can provide an actual incident where the existence of short tags hurt them, > or, the continued existence is likely to have a large negative impact on > them in the future.
I was bitten by short open tags. Despite the "no short open tag" policy in our app, one occurrence of `
  106447
August 8, 2019 16:28 arvids.godjuks@gmail.com (Arvids Godjuks)
чт, 8 авг. 2019 г. в 17:56, Robert Korulczyk <robert@korulczyk.pl>:

> > Many people have talked about the potential impacts of keeping short > tags. > > I have yet to see anyone give an actual example where they have been > > negatively impacted by their existence. I've given you my personal story > of > > how removing them will negatively impact my company. I welcome anyone > that > > can provide an actual incident where the existence of short tags hurt > them, > > or, the continued existence is likely to have a large negative impact on > > them in the future. > > I was bitten by short open tags. Despite the "no short open tag" policy in > our app, one occurrence of ` email template so it was quite hard to notice on production. Especially > that short open tags were disabled only on CLI, so we had code leak only in > emails sent by cron. It took over a month to notice that bug. > > You may be concerned about people abandoning PHP due to BC breaks, I'm > more concerned about people abandoning PHP because of issues like this. It > gives me the impression that the language wants to hurt you... > > > Regards, > Robert Korulczyk > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > I'd say this is not really a language concern and more tooling and testing
problem. It's a class of a genuine mistake everybody does from time to time - be it wrong PHP tag, HTML tag or closing } added on the wrong line resulting in a logical error. -- Arvīds Godjuks +371 26 851 664 arvids.godjuks@gmail.com Skype: psihius Telegram: @psihius https://t.me/psihius
  106449
August 8, 2019 16:54 robert@korulczyk.pl (Robert Korulczyk)
> I'd say this is not really a language concern and more tooling and testing problem. It's a class of a genuine mistake everybody does from time to time > - be it wrong PHP tag, HTML tag or closing } added on the wrong line resulting in a logical error.
This is a direct consequence of the language having settings that cause the same code to be interpreted (and works perfectly fine) in one environment and be displayed in other (without any warning). This is not the same as a typo in HTML tag or logical error in code. This is literally a tool for shooting yourself in the foot - it exists, but no one should use it. And it is still really easy to use it by accident. For example, this is what PhpStorm generates when you try to inline-comment tag with short echo: Regards, Robert Korulczyk
  106444
August 8, 2019 15:51 thruska@cubiclesoft.com (Thomas Hruska)
On 8/8/2019 3:26 AM, Côme Chilliet wrote:
> Le mercredi 7 août 2019, 15:57:02 CEST Chase Peeler a écrit : >> Pretty much everyone (if not actually >> everyone) that is against this RFC has stated that they don't actually use >> short tags, and do not advocate that anyone else use them either. > > This is what bugs me, the counter argument page from Zeev states «I never use short tags in any PHP code that I write, and as far as I recall - I never have. », > and at the same time «put hundreds of thousands of people through additional pain when upgrading.» > > Is there any data that support the theory that hundreds of thousands of people use short tags? > > Did anyone in this discussion stated that he was using them?
I used to use them extensively right up until the first RFC passed (e.g. CLI scripts, personal web apps, and some production systems). Had several thousand references to resolve but I'm off them now, whichever way this second RFC round goes. Other people chimed in that they use them too in "legacy production systems." Open source userland development demands the long open tag. So any scans of open source, public repos is going to be skewed heavily against actual use of short open tags. You simply can't rely on Composer or GitHub stats to show real-world usage numbers in this instance. So, yeah, people use them. Also, just because a lawyer, a lobbyist, or an ambassador are themselves unaffected by some issue doesn't mean they can't represent a class of an underserved population to bring forth awareness, justice, or action. In many cases, they are in better positions with sufficient contacts to reach the right people to bring forth such things that would otherwise never come to light. -- Thomas Hruska CubicleSoft President I've got great, time saving software that you will find useful. http://cubiclesoft.com/ And once you find my software useful: http://cubiclesoft.com/donate/
  106450
August 8, 2019 18:09 bishop@php.net (Bishop Bettini)
On Tue, Aug 6, 2019 at 7:34 AM G. P. B. banyard@gmail.com> wrote:

> The voting for the "Deprecate short open tags, again" [1] RFC has begun. > It is expected to last two (2) weeks until 2019-08-20. > > A counter argument to this RFC is available at > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags > > Best regards > > George P. Banyard > > [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2
I voted "yes" for removal. https://techcrunch.com/2007/08/11/facebook-source-code-leaked/ [2]:https://www.php.net/manual/en/language.basic-syntax.phptags.php
  106451
August 8, 2019 19:35 zeev@php.net (Zeev Suraski)
On Thu, Aug 8, 2019 at 9:10 PM Bishop Bettini <bishop@php.net> wrote:

> On Tue, Aug 6, 2019 at 7:34 AM G. P. B. banyard@gmail.com> wrote: > > > The voting for the "Deprecate short open tags, again" [1] RFC has begun. > > It is expected to last two (2) weeks until 2019-08-20. > > > > A counter argument to this RFC is available at > > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags > > > > Best regards > > > > George P. Banyard > > > > [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2 > > when Facebook's source code leaked precisely because of this [1]? >
Where's the evidence that it was precisely or even remotely because of this? Literally all of the PHP code leaks I've come across over the years had to do with a misconfigured Web server - e.g., load Apache without properly setting up handling for .php files, or having things like .inc files not blocked from HTTP access. As we deprecate short_tags, should we consider deprecating all SAPIs, and roll our own high-performance Web server into PHP? That's the only way to truly do away with the main vector for PHP source code leakage.
> > Much has been said about this being a "portability" issue. I think that's > overly specific. The core issue is "fallibility". You can globally > configure the language to stop recognizing itself as a language. That's > weird and unexpected. So much so, that no one gives due thought to this, > and we end up with security disasters. >
Except these are so uncommon and rare (I'm not aware of a single one, which doesn't mean there weren't any - but that they're not very common at all), that perhaps, just perhaps, it's a bit of an exaggeration to present them as a clear and present danger. PHP.net has opined, for years, that > It's time to act. So much > else breaks at the 8.0 boundary, let's do it all at once.
The "we're breaking things so badly anyway, let's break'm some more" argument has been refuted many times on this list. First, I don't think we're breaking anything really badly in PHP 8. And secondly, this remains as bad a reason as it's ever been to break stuff. Breakage is not binary - it accumulates. The more you have of it - the more difficult it is to migrate, and the slower is the migration.
> If anyone needs > to justify the effort, let them say "
It's a security hole in the exact same level that httpd.conf is a security hole. Yes, misconfiguring your Web server can have severe consequences. Thankfully, it's not nearly that big of a Thing for us to be concerned about. Zeev
  106452
August 8, 2019 19:43 zeev@php.net (Zeev Suraski)
On Thu, Aug 8, 2019 at 10:35 PM Zeev Suraski <zeev@php.net> wrote:

> > > On Thu, Aug 8, 2019 at 9:10 PM Bishop Bettini <bishop@php.net> wrote: > >> On Tue, Aug 6, 2019 at 7:34 AM G. P. B. banyard@gmail.com> wrote: >> >> > The voting for the "Deprecate short open tags, again" [1] RFC has begun. >> > It is expected to last two (2) weeks until 2019-08-20. >> > >> > A counter argument to this RFC is available at >> > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags >> > >> > Best regards >> > >> > George P. Banyard >> > >> > [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2 >> >> > when Facebook's source code leaked precisely because of this [1]? >> > > Where's the evidence that it was precisely or even remotely because of > this? >
I'd like to add that looking at the source code[1] from the leaks, it appears to be using long tags - which means that if it is authentic - short tags were not the source of the leak. Also, there was a Perl leak[2] from Facebook as well. It's a bit difficult to blame short tags for that one. Zeev [1] https://gist.github.com/nikcub/3833406 [2] https://gist.github.com/philfreo/7257723
  106455
August 8, 2019 21:12 chasepeeler@gmail.com (Chase Peeler)
On Thu, Aug 8, 2019 at 3:35 PM Zeev Suraski <zeev@php.net> wrote:

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

> On Thu, Aug 8, 2019 at 9:10 PM Bishop Bettini <bishop@php.net> wrote: > >> On Tue, Aug 6, 2019 at 7:34 AM G. P. B. banyard@gmail.com> wrote: >> >> > The voting for the "Deprecate short open tags, again" [1] RFC has begun. >> > It is expected to last two (2) weeks until 2019-08-20. >> > >> > A counter argument to this RFC is available at >> > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags >> > > > If anyone needs to justify the effort, let them say "> hole". >> > > It's a security hole in the exact same level that httpd.conf is a security > hole. Yes, misconfiguring your Web server can have severe consequences. > Thankfully, it's not nearly that big of a Thing for us to be concerned > about. >
No, not even close to the same level. If my web server's misconfigured, (ALL) of my code's exposed. It's trivial to write a test to prove that my web server is properly serving PHP files. But if PHP's misconfigured, (all OR some OR none) of my code's exposed. The only way to decide is to literally check everything. That's why I highlighted Robert Korulczyk's case study: only a particular code path in a particular environment had the problem. The status quo enables deployments to fail insecurely.
  106466
August 9, 2019 02:27 r@roze.lv ("Reinis Rozitis")
> -----Original Message----- > From: Bishop Bettini [mailto:bishop@php.net] > > That's why I highlighted Robert Korulczyk's case study: only a particular code path in a particular environment had the problem. > > The status quo enables deployments to fail insecurely. "secret"; is a trap waiting to spring. I would rather require ten thousand > people secure their environment by running a script, than risk a single person > exposing their credentials for all to steal. > > I challenge everyone who's voted no to consider this balance.
If the initial RFC would have been accepted as is (without the later proposed changes after the lengthy discussion) you would have sprung the same "trap" as in that particular case study - code would be exposed. Argument for "only a particular code path in a particular environment" is somewhat weak because in that case why does even ' .user.ini' feature exists (especially in apache sapi where you can even do engine = 0) as it also can lead to wildly different language behaviour? rr
  106478
August 9, 2019 10:27 robert@korulczyk.pl (Robert Korulczyk)
> Argument for "only a particular code path in a particular environment" is somewhat weak because in that case why does even ' .user.ini' feature exists (especially in apache sapi where you can even do engine = 0) as it also can lead to wildly different language behaviour?
Can you give an example where using `.user.ini` may create unexpected and hard to notice code leaks? Regards, Robert Korulczyk
  106480
August 9, 2019 11:16 r@roze.lv ("Reinis Rozitis")
> -----Original Message----- > From: Robert Korulczyk [mailto:robert@korulczyk.pl] > > > Can you give an example where using `.user.ini` may create unexpected and hard > to notice code leaks?
I did mention such example with the 'engine' setting ( https://www.php.net/manual/en/apache.configuration.php#ini.engine as it's PHP_INI_ALL ). Of course you could ask why would anyone do that (and afaik it's sapi specific) but technically it can happen just in one "hard to notice" subdirectory/tree. Note that atm short_tags are by default enabled and the disable happens only in php(-cli).ini so unless one throws the ini configuration files around willy nilly it is a deliberate decision from administrator. p.s. to clarify I'm not against changing the default value to disabled (to be consistent with the distributed ini-examples and (coding) recommendations) but I still don't understand what is the reason to deny for end-users the ability to change/re-enable this feature if they need it and choose so. But according to some emails for some reasons the existence of short tags now has turned out to be a major language future/feature blocker .. so go figure. rr
  106481
August 9, 2019 11:26 robert@korulczyk.pl (Robert Korulczyk)
> I did mention such example with the 'engine' setting ( https://www.php.net/manual/en/apache.configuration.php#ini.engine as it's PHP_INI_ALL ). Of course you could ask why would anyone do that (and afaik it's sapi specific) but technically it can happen just in one "hard to notice" subdirectory/tree.
This does not explain how someone could use that feature *by accident*. I gave an example where you can use short open tags by accident, and it is really easy (the most popular IDE sometimes generates code with short open tags) and hard to notice (it is not easy to spot a difference between `
  106485
August 9, 2019 12:26 r@roze.lv ("Reinis Rozitis")
> This does not explain how someone could use that feature *by accident*. I gave > an example where you can use short open tags by accident, and it is really easy > (the most popular IDE sometimes generates code with short open tags) and hard > to notice (it is not easy to spot a difference between ` you compare this to situation when you create a separate file with an explicit > directive to disable PHP engine, and then be surprised that code is not executed?
Disabling short tags now is done with "an explicit directive" (there has to be a specific ini file with a specific setting 'short_open_tag = 0'). Isn't this the same "situation when you create a separate file with an explicit directive"? If a coder (or IDE) has written '
  106492
August 9, 2019 13:24 robert@korulczyk.pl (Robert Korulczyk)
> Disabling short tags now is done with "an explicit directive" (there has to be a specific ini file with a specific setting 'short_open_tag = 0'). > Isn't this the same "situation when you create a separate file with an explicit directive"?
No, it's not. `php.ini` is outside of project responsibility - as a developer you don't really configure this in any way, your application does not have any explicit directive to disable/enable short open tags. You just accidentally using feature that could lead to code leak. In your example with `engine` directive you explicitly disable PHP engine by creating dedicated file for that purpose - there is no way do to this by accident and then does not notice it.
> If a coder (or IDE) has written ' exactly the same if the feature suddenly disappeared (unless the additional checks in the 'v2 RFC' which on the other hand would make the engine a > tiny bit slower but probably have to be implemented to avoid such accidents).
At least the this behavior will be consistent - you will not have cases when code works fine on one environment and leak on another. Regards, Robert Korulczyk
  106553
August 12, 2019 08:29 kris.craig@gmail.com (Kris Craig)
On Fri, Aug 9, 2019 at 6:25 AM Robert Korulczyk <robert@korulczyk.pl> wrote:

> > Disabling short tags now is done with "an explicit directive" (there has > to be a specific ini file with a specific setting 'short_open_tag = 0'). > > Isn't this the same "situation when you create a separate file with an > explicit directive"? > > No, it's not. `php.ini` is outside of project responsibility - as a > developer you don't really configure this in any way, your application does > not > have any explicit directive to disable/enable short open tags. You just > accidentally using feature that could lead to code leak. > In your example with `engine` directive you explicitly disable PHP engine > by creating dedicated file for that purpose - there is no way do to this by > accident and then does not notice it. > > > > If a coder (or IDE) has written ' unless tested the effect (a part of code not being parsed/executed) will be > > exactly the same if the feature suddenly disappeared (unless the > additional checks in the 'v2 RFC' which on the other hand would make the > engine a > > tiny bit slower but probably have to be implemented to avoid such > accidents). > > At least the this behavior will be consistent - you will not have cases > when code works fine on one environment and leak on another. > > > Regards, > Robert Korulczyk > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > So far, the RFC only has 55% support, which means it's not going to pass
this time, anyway, unless there's a vote shift in the next 8 days.
  106662
August 20, 2019 12:51 george.banyard@gmail.com ("G. P. B.")
Hello internals,

This RFC has been declined with 56% in favour (30/54) and 44% against
(24/54).

Two side notes to this:

  - I seriously don't appreciate that the RFC has been edited *WITHOUT* my
knowledge to add endorsement names on the counterargument to the RFC on the
RFC itself  when the appropriate place would have been the counter argument
document.
  - As it has no clear supra majority (nor against nor in favour), this
topic should probably be put to discussion again in some way or form at a
later stage.

Best regards

George P. Banyard
  106663
August 20, 2019 14:47 rowan.collins@gmail.com (Rowan Tommins)
On 20/08/2019 13:51, G. P. B. wrote:
> - I seriously don't appreciate that the RFC has been edited*WITHOUT* my > knowledge to add endorsement names on the counterargument to the RFC on the > RFC itself when the appropriate place would have been the counter argument > document.
While I appreciate that there is a certain implication of "ownership" when you are the author of an RFC, it is ultimately a resource for the community as a whole to understand the discussion, which is why the guide at https://wiki.php.net/rfc/howto explicitly mentions including both positive and negative feedback. The only problem I can see with other people editing "your" RFC is if later readers could mistake the edits for your own opinion; even if the whole counter-argument had been a section rather than a separate page, it would be clear that readers shouldn't do that. In this case, the only edits are to add a list of names, which is basically what the voting widget does anyway, so I really can't see any reason to be upset about it. Regards, -- Rowan Tommins (né Collins) [IMSoP]
  106671
August 20, 2019 17:44 george.banyard@gmail.com ("G. P. B.")
2019年8月20日(火) 16:47 Rowan Tommins collins@gmail.com>:

> On 20/08/2019 13:51, G. P. B. wrote: > > - I seriously don't appreciate that the RFC has been edited*WITHOUT* > my > > knowledge to add endorsement names on the counterargument to the RFC on > the > > RFC itself when the appropriate place would have been the counter > argument > > document. > > > While I appreciate that there is a certain implication of "ownership" > when you are the author of an RFC, it is ultimately a resource for the > community as a whole to understand the discussion, which is why the > guide at https://wiki.php.net/rfc/howto explicitly mentions including > both positive and negative feedback. > > The only problem I can see with other people editing "your" RFC is if > later readers could mistake the edits for your own opinion; even if the > whole counter-argument had been a section rather than a separate page, > it would be clear that readers shouldn't do that. In this case, the only > edits are to add a list of names, which is basically what the voting > widget does anyway, so I really can't see any reason to be upset about it.. > > Regards, > > -- > Rowan Tommins (né Collins) > [IMSoP] > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php
Citation:
> Note: An RFC is effectively “owned” by the person that created it. If you > want to make changes, get permission from the creator.
Taken from: https://wiki.php.net/rfc I'm upset that a voting document is edited without my knowledge, and I don't see why I haven't been asked (probably because I would have said no to the edits) On Tue, 20 Aug 2019 at 17:18, Sara Golemon <pollita@php.net> wrote:
> This has been a topic of discussion in the past. The agreement was that > non-author edits are permitted if they are isolated to a clear > "counter-arguments" section. If someone had changed the meaning of the RFC > or of your arguments in favor of it that would be another story, but that's > not what happened here. > > -Sara >
Gotcha so from now on I'll just add a sentence "George Peter Banyard supports this RFC" every time I'm in agreement with an RFC to the RFC because having your name tied to a vote is apparently irrelevant, because this is exactly what you did (but only on the RFC not the counter argument page). On Tue, 20 Aug 2019 at 18:02, Chase Peeler <chasepeeler@gmail.com> wrote:
> > I think that now we need to fix the documentations out there. short > > tags will stay in PHP for at least another 10+ years, so maybe we > > should simply consider them not a part of legacy but a special kind of > > a feature. There are some parts in PHP comments and docs that needs > > this fixed and sorted out better a bit (probably - specially in the > > ini files itself etc). > > > > I think we should still discourage their use. We should be explicit in > the > documentation that code which uses short tags might not be portable. Just > because they exist, doesn't mean we should suddenly change our treatment of > them when it comes to best practices. If there is any documentation that > doesn't make this clear, submit a bug report.
The document has been discouraging their use for god knows how long.
> PHP also allows for short open tag * only available if enabled using the short_open_tag > <https://www.php.net/manual/en/ini.core.php#ini.short-open-tag> php.ini > configuration file directive, or if PHP was configured with the > *--enable-short-tags* option). >
See: https://www.php.net/manual/en/language.basic-syntax.phptags.php On a final note, I don't think I have anything more to add to this topic so I probably won't respond to subsequent messages in this thread. Best regards George Peter Banyard
  106673
August 20, 2019 17:48 pollita@php.net (Sara Golemon)
On Tue, Aug 20, 2019 at 12:44 PM G. P. B. banyard@gmail.com> wrote:

> > This has been a topic of discussion in the past. The agreement was that > > non-author edits are permitted if they are isolated to a clear > > "counter-arguments" section. If someone had changed the meaning of the > RFC > > or of your arguments in favor of it that would be another story, but > that's > > not what happened here. > > > > Gotcha so from now on I'll just add a sentence "George Peter Banyard > supports this RFC" every time I'm in agreement with an RFC to the RFC > because having your name tied to a vote is apparently irrelevant, because > this is exactly what you did (but only on the RFC not the counter argument > page). > > Gotcha. So you're not actually conversing in good faith. That's helpful to know.
  106664
August 20, 2019 15:18 pollita@php.net (Sara Golemon)
On Tue, Aug 20, 2019 at 7:51 AM G. P. B. banyard@gmail.com> wrote:

> - I seriously don't appreciate that the RFC has been edited *WITHOUT* my > knowledge to add endorsement names on the counterargument to the RFC on the > RFC itself when the appropriate place would have been the counter argument > document. > > This has been a topic of discussion in the past. The agreement was that non-author edits are permitted if they are isolated to a clear
"counter-arguments" section. If someone had changed the meaning of the RFC or of your arguments in favor of it that would be another story, but that's not what happened here. -Sara
  106665
August 20, 2019 15:50 peterkokot@gmail.com (Peter Kokot)
On Tue, 20 Aug 2019 at 14:51, G. P. B. banyard@gmail.com> wrote:
> > Hello internals, > > This RFC has been declined with 56% in favour (30/54) and 44% against > (24/54). > > Two side notes to this: > > - I seriously don't appreciate that the RFC has been edited *WITHOUT* my > knowledge to add endorsement names on the counterargument to the RFC on the > RFC itself when the appropriate place would have been the counter argument > document. > - As it has no clear supra majority (nor against nor in favour), this > topic should probably be put to discussion again in some way or form at a > later stage. > > Best regards > > George P. Banyard
The number of things that got wrong in these two RFCs is extraordinary. If anything the community, the internals and everyone involved got through a good thinking process so we have learned something from this in any way. I appreciate all your time and effort to move this thing forward and even for being so respectful towards Zeev, Rasmus, Dmitry, and Sara who have endorsed keeping them in the PHP and to repeat the voting with a better solution in this RFC. I think that now we need to fix the documentations out there. short tags will stay in PHP for at least another 10+ years, so maybe we should simply consider them not a part of legacy but a special kind of a feature. There are some parts in PHP comments and docs that needs this fixed and sorted out better a bit (probably - specially in the ini files itself etc). -- Peter Kokot
  106666
August 20, 2019 16:02 chasepeeler@gmail.com (Chase Peeler)
On Tue, Aug 20, 2019 at 11:50 AM Peter Kokot <peterkokot@gmail.com> wrote:

> On Tue, 20 Aug 2019 at 14:51, G. P. B. banyard@gmail.com> wrote: > > > > Hello internals, > > > > This RFC has been declined with 56% in favour (30/54) and 44% against > > (24/54). > > > > Two side notes to this: > > > > - I seriously don't appreciate that the RFC has been edited *WITHOUT* > my > > knowledge to add endorsement names on the counterargument to the RFC on > the > > RFC itself when the appropriate place would have been the counter > argument > > document. > > - As it has no clear supra majority (nor against nor in favour), this > > topic should probably be put to discussion again in some way or form at a > > later stage. > > > > Best regards > > > > George P. Banyard > > The number of things that got wrong in these two RFCs is > extraordinary.
What was done incorrectly in regards to the second RFC?
> If anything the community, the internals and everyone > involved got through a good thinking process so we have learned > something from this in any way. I appreciate all your time and effort > to move this thing forward and even for being so respectful towards > Zeev, Rasmus, Dmitry, and Sara who have endorsed keeping them in the > PHP and to repeat the voting with a better solution in this RFC. > > You say that like being respectful to people with opinion different than yours is something worth commending, when it should be the default
behavior. In other words, you are implying that anyone that opposed this RFC didn't deserve respect, so, congratulations to everyone for showing it anyway.
> I think that now we need to fix the documentations out there. short > tags will stay in PHP for at least another 10+ years, so maybe we > should simply consider them not a part of legacy but a special kind of > a feature. There are some parts in PHP comments and docs that needs > this fixed and sorted out better a bit (probably - specially in the > ini files itself etc). > > I think we should still discourage their use. We should be explicit in the documentation that code which uses short tags might not be portable. Just
because they exist, doesn't mean we should suddenly change our treatment of them when it comes to best practices. If there is any documentation that doesn't make this clear, submit a bug report. If you really feel that we should start treating short tags as totally legitimate, then someone else with better knowledge of how to proceed with that will need to provide advice.
> -- > Peter Kokot > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- Chase Peeler chasepeeler@gmail.com
  106667
August 20, 2019 16:18 peterkokot@gmail.com (Peter Kokot)
On Tue, 20 Aug 2019 at 18:02, Chase Peeler <chasepeeler@gmail.com> wrote:
> > On Tue, Aug 20, 2019 at 11:50 AM Peter Kokot <peterkokot@gmail.com> wrote: > > > On Tue, 20 Aug 2019 at 14:51, G. P. B. banyard@gmail.com> wrote: > > > > > > Hello internals, > > > > > > This RFC has been declined with 56% in favour (30/54) and 44% against > > > (24/54). > > > > > > Two side notes to this: > > > > > > - I seriously don't appreciate that the RFC has been edited *WITHOUT* > > my > > > knowledge to add endorsement names on the counterargument to the RFC on > > the > > > RFC itself when the appropriate place would have been the counter > > argument > > > document. > > > - As it has no clear supra majority (nor against nor in favour), this > > > topic should probably be put to discussion again in some way or form at a > > > later stage. > > > > > > Best regards > > > > > > George P. Banyard > > > > The number of things that got wrong in these two RFCs is > > extraordinary. > > What was done incorrectly in regards to the second RFC? > > > > If anything the community, the internals and everyone > > involved got through a good thinking process so we have learned > > something from this in any way. I appreciate all your time and effort > > to move this thing forward and even for being so respectful towards > > Zeev, Rasmus, Dmitry, and Sara who have endorsed keeping them in the > > PHP and to repeat the voting with a better solution in this RFC. > > > > You say that like being respectful to people with opinion different than > yours is something worth commending, when it should be the default > behavior. In other words, you are implying that anyone that opposed this > RFC didn't deserve respect, so, congratulations to everyone for showing it > anyway. > > > > I think that now we need to fix the documentations out there. short > > tags will stay in PHP for at least another 10+ years, so maybe we > > should simply consider them not a part of legacy but a special kind of > > a feature. There are some parts in PHP comments and docs that needs > > this fixed and sorted out better a bit (probably - specially in the > > ini files itself etc). > > > > I think we should still discourage their use. We should be explicit in the > documentation that code which uses short tags might not be portable. Just > because they exist, doesn't mean we should suddenly change our treatment of > them when it comes to best practices. If there is any documentation that > doesn't make this clear, submit a bug report. > > If you really feel that we should start treating short tags as totally > legitimate, then someone else with better knowledge of how to proceed with > that will need to provide advice. >
Let's simplify this a bit because I'm not sure I have seen anyone mentioning something like a PHP 10 milestone in all these discussions. If we want to get rid of some feature like this a very long timeline needs to be done and also major versions needs to be taken into consideration. And from all the discussions I got a feeling that not everyone who voted "No" (who want the short tags in PHP) also want to get rid of them. Ever. So that's why. We can live with short tags in PHP as a feature. And so can legacy projects be upgraded to not use them anymore so nothing to worry too much I think anymore now. We'll discuss this maybe in 5 or 10 years then. About the docs - there are very minor changes needed where "backwards compatibility" is mentioned maybe. Because they are not in PHP for keeping BC anymore now. Nobody proposed a better solution than this RFC, then they are a feature. Cheers. -- Peter Kokot
  106668
August 20, 2019 16:39 rowan.collins@gmail.com (Rowan Tommins)
On 20/08/2019 17:18, Peter Kokot wrote:
> About the docs - there are > very minor changes needed where "backwards compatibility" is mentioned > maybe. Because they are not in PHP for keeping BC anymore now. Nobody > proposed a better solution than this RFC, then they are a feature.
Being "for Backwards Compatibility" and being "there forever" are not mutually exclusive. There are a huge number of things in this world which exist only to be compatible with an older technology or use case, but which will never be phased out, because the effort to change them exceeds the benefit. On the other hand, I think it might be useful to have a status of "officially discouraged" distinct from "deprecated". I occasionally hear people ask to "deprecate" something without any particular timeline or criteria for when it would be removed; my suspicion is that what they really want is a clearer message to users that they shouldn't use the feature. Regards, -- Rowan Tommins (né Collins) [IMSoP]
  106669
August 20, 2019 16:56 peterkokot@gmail.com (Peter Kokot)
On Tue, 20 Aug 2019 at 18:39, Rowan Tommins collins@gmail.com> wrote:
> > On 20/08/2019 17:18, Peter Kokot wrote: > > About the docs - there are > > very minor changes needed where "backwards compatibility" is mentioned > > maybe. Because they are not in PHP for keeping BC anymore now. Nobody > > proposed a better solution than this RFC, then they are a feature. > > > Being "for Backwards Compatibility" and being "there forever" are not > mutually exclusive. There are a huge number of things in this world > which exist only to be compatible with an older technology or use case, > but which will never be phased out, because the effort to change them > exceeds the benefit. > > On the other hand, I think it might be useful to have a status of > "officially discouraged" distinct from "deprecated". I occasionally hear > people ask to "deprecate" something without any particular timeline or > criteria for when it would be removed; my suspicion is that what they > really want is a clearer message to users that they shouldn't use the > feature. > > Regards,
Probably. But fact is that PHP opening short tags can be used. We can enable them in controlled environments and use the short tags knowing they will never be removed now. No deprecation warning is standing in our way to do that now. And such code (or better put app) is honestly now also not so bad. Because it will still work in at least let's say, PHP 9 at least or considering the feedback and discussions for ever... Also users who are already using short tags can now postpone the upgrades for another ~5+ years at least :) -- Peter Kokot
  106670
August 20, 2019 17:39 rowan.collins@gmail.com (Rowan Tommins)
On 20/08/2019 17:56, Peter Kokot wrote:
> Probably. But fact is that PHP opening short tags can be used. We can > enable them in controlled environments and use the short tags knowing > they will never be removed now. No deprecation warning is standing in > our way to do that now. And such code (or better put app) is honestly > now also not so bad. Because it will still work in at least let's say, > PHP 9 at least or considering the feedback and discussions for ever... > Also users who are already using short tags can now postpone the > upgrades for another ~5+ years at least :)
I don't think anything has changed in that regard. If there's text in the manual that short open tags are deprecated then it was wrong before this pair of RFCs; if there's text in the manual stating other reasons not to use them (portability, possibility of mixing in XML, etc) then it is still just as valid as it ever was. If your impression was that the feature was already deprecated before the v1 RFC, and has somehow become *less* deprecated as a result of this vote, that may be explain some of the disconnect over the issue. As far as I'm aware, it had no such status, it was simply a feature that used to be more commonly used than it is today. Regards, -- Rowan Tommins (né Collins) [IMSoP]
  106672
August 20, 2019 17:46 phpmailinglists@gmail.com (Peter Bowyer)
On Tue, 20 Aug 2019 at 17:18, Peter Kokot <peterkokot@gmail.com> wrote:

> Let's simplify this a bit because I'm not sure I have seen anyone > mentioning something like a PHP 10 milestone in all these discussions. > If we want to get rid of some feature like this a very long timeline > needs to be done and also major versions needs to be taken into > consideration. >
It does indeed, and this approach was proposed by myself and another person. The approach was: add the deprecation notice in PHP 8, and remove short open tags in PHP 9 or PHP 10 (purposely left vague to get more support for the idea - as getting the deprecation underway is the most important move). It met with deafening silence. Peter
  106679
August 20, 2019 21:18 peterkokot@gmail.com (Peter Kokot)
On Tue, 20 Aug 2019 at 19:47, Peter Bowyer <phpmailinglists@gmail.com> wrote:
> > On Tue, 20 Aug 2019 at 17:18, Peter Kokot <peterkokot@gmail.com> wrote: >> >> Let's simplify this a bit because I'm not sure I have seen anyone >> mentioning something like a PHP 10 milestone in all these discussions. >> If we want to get rid of some feature like this a very long timeline >> needs to be done and also major versions needs to be taken into >> consideration. > > > It does indeed, and this approach was proposed by myself and another person. > > The approach was: add the deprecation notice in PHP 8, and remove short open tags in PHP 9 or PHP 10 (purposely left vague to get more support for the idea - as getting the deprecation underway is the most important move). > > It met with deafening silence. > > Peter
Then I apologize if your suggestion has been missed to do that like this (there were too many emails stuck in loops and probably time period of 5 to 10 years in the future is a bit problematic to understand, and last but not least a bit of an issue when there is a very clear feedback from people present since day 1 where they recommend something else). I guess we should really highlight also such option and discuss this more rationally back then. Now, we have postponed this until who knows when and also without any clear guideline for what will happen with short tags if they will be ever removed or not... -- Peter Kokot
  106680
August 20, 2019 21:37 rowan.collins@gmail.com (Rowan Tommins)
On 20/08/2019 22:18, Peter Kokot wrote:
>> The approach was: add the deprecation notice in PHP 8, and remove short open tags in PHP 9 or PHP 10 (purposely left vague to get more support for the idea - as getting the deprecation underway is the most important move). >> > I guess we should really highlight also > such option and discuss this more rationally back then. Now, we have > postponed this until who knows when and also without any clear > guideline for what will happen with short tags if they will be ever > removed or not...
I honestly don't think it would make any difference to most people who voted against. The counter-arguments people have presented, again and again, are not about the pace of removal, but about whether removal is needed at all. If anyone wants to revive this proposal in future, it is that counter-argument that they would need to understand and address. Regards, -- Rowan Tommins (né Collins) [IMSoP]
  106681
August 20, 2019 21:43 peterkokot@gmail.com (Peter Kokot)
On Tue, 20 Aug 2019 at 23:37, Rowan Tommins collins@gmail.com> wrote:
> > On 20/08/2019 22:18, Peter Kokot wrote: > >> The approach was: add the deprecation notice in PHP 8, and remove short open tags in PHP 9 or PHP 10 (purposely left vague to get more support for the idea - as getting the deprecation underway is the most important move). > >> > > I guess we should really highlight also > > such option and discuss this more rationally back then. Now, we have > > postponed this until who knows when and also without any clear > > guideline for what will happen with short tags if they will be ever > > removed or not... > > > I honestly don't think it would make any difference to most people who > voted against. The counter-arguments people have presented, again and > again, are not about the pace of removal, but about whether removal is > needed at all. If anyone wants to revive this proposal in future, it is > that counter-argument that they would need to understand and address. > > Regards,
I think so too, yes. We will have the same discussion... I'll leave it be. I just have my own opinion about them. Facts are facts (what software does and allows to do) and what documentation and code comments say (something completely different). What is programmer advised to do is not the same as what can programmer do with the language. That's all. -- Peter Kokot