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
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.
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_tagsBest regards
George P. Banyard
--
Chase Peeler
chasepeeler@gmail.com
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]
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
Hello,
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
On Tue, 6 Aug 2019 at 19:12, Rowan Collins rowan.collins@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
On Tue, 6 Aug 2019 at 19:12, Rowan Collins rowan.collins@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
Hi,
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.
Hello,
Hi,
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.--
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
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
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
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
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
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
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
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
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
On Wed, Aug 7, 2019 at 4:56 PM Dan Ackroyd Danack@basereality.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#105558I'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
--
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
Hello.
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#105558I'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
--
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
Hello.
On Wed, Aug 7, 2019 at 12:45 PM Peter Kokot peterkokot@gmail.com
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#105558I'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
--
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.comJust 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
Hello,
Hello.
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#105558I'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
--
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.comJust 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
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
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
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
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
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
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]
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
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
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
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_tagsBest regards
George P. Banyard
Side-note: Even if this RFC fails, we should probably still make it an
error to use <? without short_tags being explicitly enabled, so that 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
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_tagsBest regards
George P. Banyard
Side-note: Even if this RFC fails, we should probably still make it an
error to use <? without short_tags being explicitly enabled, so that 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.
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
Le 6 août 2019 à 20:46, Nikita Popov nikita.ppv@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_tagsBest regards
George P. Banyard
Side-note: Even if this RFC fails, we should probably still make it an
error to use <? without short_tags being explicitly enabled, so that 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 <?xml ?> declaration. I doubt that this is a more acceptable breaking change than deprecating short_tags.
—Claude
Le 6 août 2019 à 20:46, Nikita Popov nikita.ppv@gmail.com a écrit :
On Tue, Aug 6, 2019 at 1:34 PM G. P. B. george.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_tagsBest regards
George P. Banyard
Side-note: Even if this RFC fails, we should probably still make it an
error to use <? without short_tags being explicitly enabled, so that
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<?xml ?>declaration.
I doubt that this is a more acceptable breaking change than deprecating
short_tags.—Claude
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
Le 6 août 2019 à 20:46, Nikita Popov nikita.ppv@gmail.com a écrit :
On Tue, Aug 6, 2019 at 1:34 PM G. P. B. george.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_tagsBest regards
George P. Banyard
Side-note: Even if this RFC fails, we should probably still make it an
error to use <? without short_tags being explicitly enabled, so that
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<?xml ?>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 <? results in an error if and
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 <?xml
?> 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
To clarify: What I had in mind is that use of <? results in an error if and
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 <?xml
?> 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 "<?" other than "<?php" and "<?=" would raise an
error; compile-time default - off: "<?" is ignored and passed through to output; ini default shipped
by most packages - on: "<?" is equivalent to "<?php"; no longer any kind of default
We could either leave the recommended ini setting in the official
distribution as "off" (more compatible) or set it to "error" (to make
mistakes safer and easier to spot).
Regards.
--
Rowan Collins
[IMSoP]
Le mar. 6 août 2019 à 13:34, G. P. B. george.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_tagsBest regards
George P. Banyard
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
On Wed, Aug 7, 2019 at 1:14 PM Nicolas Grekas nicolas.grekas+php@gmail.com
wrote:
Le mar. 6 août 2019 à 13:34, G. P. B. george.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_tagsBest regards
George P. Banyard
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. <? and <?php. 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.
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
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?
-----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
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
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?
-----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
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]
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
I asked similar questions on Twitter, where Zeev replied the following:
https://mobile.twitter.com/zeevs/status/1158688885658046464I 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
Hello,
I asked similar questions on Twitter, where Zeev replied the following:
https://mobile.twitter.com/zeevs/status/1158688885658046464I 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
чт, 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--
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
<?php and <?= and that's it.
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.
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.
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.
--
Arvīds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius
On Thu, 8 Aug 2019 at 16:18, Arvids Godjuks arvids.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]
On Thu, Aug 8, 2019 at 11:18 AM Arvids Godjuks arvids.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--
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
<?phpand<?=and that's it.
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 dosystemctl reload nginx,
hitting the URL and getting myindex.phpon 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
чт, 8 авг. 2019 г. в 17:42, Chase Peeler chasepeeler@gmail.com:
On Thu, Aug 8, 2019 at 11:18 AM Arvids Godjuks arvids.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--
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
<?phpand<?=and that's it.
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 dosystemctl reload nginx,
hitting the URL and getting myindex.phpon 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
<? to a point of using veto rights or pulling their weight or whatever
can happen - leave them in (though I'm strongly against that), but the
runtime switch needs to go.
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
Hello,
I asked similar questions on Twitter, where Zeev replied the
following:
https://mobile.twitter.com/zeevs/status/1158688885658046464I 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
withoutany 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.comThanks 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
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 <? slipped through code review. It was in
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
чт, 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<?slipped through code review. It was in
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--
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
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:
<?//= 'test' ?>
Regards,
Robert Korulczyk
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.
And once you find my software useful:
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_tagsBest regards
George P. Banyard
I voted "yes" for removal. <? is a security risk. If your code uses <?,
then your code is liable to leak, based entirely on a setting potentially
out of your control. As Robert Korulczyk's example illustrates, even within
the same organization, misconfigurations can have hidden and drastic
consequences.
<? is a security risk today, just as much as it was then. Remember in 2007
when Facebook's source code leaked precisely because of this 1?
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.
PHP.net has opined, for years, that <? is bad2. It's time to act. So much
else breaks at the 8.0 boundary, let's do it all at once. If anyone needs
to justify the effort, let them say "<? is a security hole".
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_tagsBest regards
George P. Banyard
<? is a security risk today, just as much as it was then. Remember in 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 <? is bad[2].
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 "<? is a security 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.
Zeev
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_tagsBest regards
George P. Banyard
<? is a security risk today, just as much as it was then. Remember in 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?
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
On Tue, Aug 6, 2019 at 7:34 AM G. P. B. george.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_tagsBest regards
George P. Banyard
<? is a security risk today, just as much as it was then. Remember in
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 <? is bad[2].
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 "<? is a security 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.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
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_tagsIf anyone needs to justify the effort, let them say "<? is a security
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. <? $dbpassword =
"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.
-----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. <? $dbpassword =
"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
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
-----Original Message-----
From: Robert Korulczyk [mailto:robert@korulczyk.pl]Can you give an example where using
.user.inimay 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
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 <?
and <?php). How can you compare this to situation when you create a separate file with an explicit directive to disable PHP engine, and then be
surprised that code is not executed?
Regards,
Robert Korulczyk
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<?and<?php). How can
you compare this to situation when you create a separate file with an explicit
directive to disable PHP engine, and then be surprised that code is not executed?
Disabling short tags now is done with "an explicit directive" (there has to be a specific ini file with a specific setting 'short_open_tag = 0').
Isn't this the same "situation when you create a separate file with an explicit directive"?
If a coder (or IDE) has written '<?', '<%' or by accident any other tag 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).
rr
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 '<?', '<%' or by accident any other tag 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
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.iniis 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 withenginedirective 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 '<?', '<%' or by accident any other tag
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--
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.
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
- I seriously don't appreciate that the RFC has been editedWITHOUT 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]
2019年8月20日(火) 16:47 Rowan Tommins rowan.collins@gmail.com:
- I seriously don't appreciate that the RFC has been editedWITHOUT
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]--
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)
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).
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 <? (which is discouraged since it is
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
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.
- 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
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
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--
--
Chase Peeler
chasepeeler@gmail.com
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
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]
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
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]
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
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
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]
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