Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
Seems good to me. Short tags have long presented a risk of code leakage and lack of portability, since they are dependent on an ini setting which not everyone has enabled. Hopefully this can land in time for PHP 7.4. From: Nikita Popov Sent: Monday, June 17, 2019 5:55 AM To: Peter Kokot Cc: Zeev Suraski; G. P. B.; Stanislav Malyshev; Derick Rethans; PHP Internals List Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags On Fri, May 24, 2019 at 6:53 PM Peter Kokot wrote: > Hello, > > On Sat, 11 May 2019 at 20:56, Peter Kokot wrote: > > > > Not trying to rush anyone to something they have no energy working on > > anymore here but what's the plan here then? And what plan is there > > with these short tags on the long run? > > I'm just checking then why is this RFC in the pending implementation > state if basically we're on a way to have the short opening tags in > PHP for ever... Maybe we should then enable them by default to have > the other way around situation of having both tags for few 10 years > and then ditch the long one if it's not going to be deprecated in PHP > 7.4 and decided what to do with them? > > https://wiki.php.net/rfc/deprecate_php_short_tags > Girgias has put up a new implementation at https://github.com/php/php-src/pull/4263. If short_open_tag=On and
Re: [PHP-DEV] Stop replacing dots with underscores in query, post and cookie parameters for PHP 8?
On Tue, Jul 16, 2019 at 2:34 PM Bishop Bettini wrote: > On Tue, Jul 16, 2019 at 3:51 AM Nikita Popov wrote: > > > On Tue, Jul 16, 2019 at 3:40 AM Arnold Daniels < > > arnold.adaniels...@gmail.com> > > wrote: > > > > > Hi, > > > > > > PHP replaces dots with underscores for $_GET, $_POST and $_COOKIE. This > > > behavior once made sense because of Register globals. The explanation > in > > > the manual also still implies that query and post parameters are > > converted > > > to variables (see > > > > > > https://php.net/manual/en/language.variables.external.php#language.variables.external.dot-in-names > > ). > > > Register globals has been removed since 5.4.0 and thus this behavior > > serves > > > little purpose. > > > > > > I think it would be good to remove the conversion in PHP 8, as it's a > > > general cause of confusion and annoyance for anyone who comes across > it. > > > > > > Is there a good reason to keep this behavior in PHP 8? > > > > > > > This has been discussed a few times already, and I think that everyone > > agrees that this behavior should go, but not necessarily on the migration > > path. There is an RFC here: > > https://wiki.php.net/rfc/on_demand_name_mangling > > I think that the latest version of that RFC, that basically proposes to > > drop the behavior and tell people to use a polyfill is fine. > > > > I've readied the proposal for formal discussion. As proposed: > >- PHP 8.0 will no longer mangle variable names in any super-global. >- The changelog will recommend auditing super-global access for mangled >names, and replacing with the actual variable name. >- No INI settings will engage the behavior. >- No warnings or notices will be emitted. >- A polyfill will be made available to emulate that original behavior. >- Applications requiring name mangling shall invoke the polyfill during >bootstrap phase. > > https://wiki.php.net/rfc/on_demand_name_mangling Can you please start a new [RFC] thread for this? Nikita
Re: [PHP-DEV] Re: hebrevc() and other 'contentious' 7.4 proposed deprecations
On Tue, 16 Jul 2019 at 17:00, Zeev Suraski wrote: > On Tue, Jul 16, 2019 at 7:34 AM G. P. B. wrote: > >> The RFC process establishes a consensus when 2/3 of the voters agree, >> which is currently the case. >> > > As the author of that RFC, I can tell you with complete confidence that > deprecations were not in the intended scope of that process. It's quite > evident from the language of the Voting RFC itself: > > "Given that changes to languages (as opposed to changes to apps or even > frameworks) are for the most part irreversible - the purpose of the vote is > to ensure that there's strong support for the proposed feature." > > If the bar to remove a feature is identical to introducing it - it's > hardly irreversible. The current behavior was never ever intended. It > wasn't even supposed to be used for deprecations - but for new features. > It seems this mention has been removed after the amendment from the "Abolish Narrow Margin" RFC, and I'm also seeing that there hasn't been any amendment made to the document after the "Abolish Short Votes" RFC passed". I personally don't see the problem of having deprecation with the same threshold as feature for voting, which is only mandatory since the Narrow Margin RFC came into effect, but this is only my opinion. If you feel that strong about correcting this issue you could make an RFC to amend the Voting RFC/Process, like Joe did (twice), to add a special case for feature deprecation. And no I don't think the voting process need a complete revamp. Also, I just want to point out that, IMHO, the main reason for the high amount of deprecations for PHP 7.4 is that it is the last minor version before the next major. And who know how long it is going to take to have the next major (supposedly 5 years) which is a long time in tech. > An argument could be made that this isn't a large enough consensus - >> something I don't agree with - however, at the time of writing this, all >> the deprecations even pass a 3/4 consensus [4]. >> > > I think there are at least two issues that in a healthy environment would > be needed: > > - A clear, tangible benefit to the deprecation. Having another way of > doing something certainly does not constitute a clear, tangible benefit to > removing a feature. This should be a pre-requisite for a deprecation. In > the past it was an obvious, implicit requirement - but that's from the days > where we weren't as 'litigative', so it may make sense to explicitly point > it out for the future. > This ties in to the point above about making an amendment to the Voting process. > - A much stronger consensus, that prevents the tyranny of the majority in > such cases. Whether it should be 100% or 95% - but it certainly shouldn't > be 2/3 or even 3/4 - and should put into affect the notion that 'changes to > the language are for the most part irreversible' - which was a fundamental > tenet of the Voting RFC. > > Zeev > These thresholds are, in my mind, pure insanity. Let's run some numbers on how little people do you need to make a vote fail with 95% (because 100% is always 1): 10 voters: 1 person (need 9.5 voters in favour), 15 voters: 1 person (need 14.25 voters in favour) , 20 voters: 2 people (need 19 voters in favour) , 25 voters: 2 people (need 23.75 voters in favour) , 30 voters: 2 people (need 28.5 voters in favour, which is usually how many people vote for "normal" RFC from what I see 35 voters: 2 people (need 33.25 voters in favour) 40 voters: 3 people (need 38 voters in favour) about the number of people currently voting on the PHP 7.4 deprecations RFC 45 voters: 3 people (need 42.75 voters in favour) 50 voters: 3 people (need 47.5 voters in favour) 55 voters: 3 people (need 52.25 voters in favour) high profile RFCs 60 voters: 4 people (need 57 voters in favour) 65 voters: 4 people (need 61.75 voters in favour) 70 voters: 4 people (need 66.5 voters in favour) Typed property V2 RFC (super high profile RFC) 75 voters: 4 people (need 71.25 voters in favour) 80 voters: 5 people (need 76 voters in favour) This is madness: to make a vote fail you just need to find, with current voting turnout, 2 other people to make a vote fail. Sure it is possible for a tyranny of the majority but with these threshold there is also clearly a tyranny of a minority because 56 voters in favour and 3 against is IMHO a clear statement of consensus but would fail with a 95% majority. And I don't think a 90% threshold is that much better. I think the highest threshold I would possibly go with high discomfort is 80% (4/5). I know that you're aren't necessarily keen on having so many people able to vote, which is the opposite of what I believe as I think the more people vote the better and more reflective of a vote we get. That's why we are always going to end in disagreement about these things IMO as we have opposite philosophies. Side note: I replied to you resending this email is to let you know that at least *someone* has read it -even
Re: [PHP-DEV] Re: hebrevc() and other 'contentious' 7.4 proposed deprecations
On Tue, Jul 16, 2019 at 7:34 AM G. P. B. wrote: > On Tue, 16 Jul 2019 at 16:18, Zeev Suraski wrote: > Secondly the word you are looking for here is "unanimity"/"unanimous" as > per the Cambridge dictionary [1]: > >> *If a group of people are unanimous, they all agree about one particular >> matter or vote the same way, and if a decision or judgment is unanimous, it >> is formed or supported by everyone in a group* > > > As consensus means, also from the Cambridge dictionary [2]: > >> *a generally accepted opinion or decision among a group of people* >> > > Now unanimity implies consensus however not having a unanimous vote does > not mean there is no consensus. > Moreover, even though "consensus" does come from the Latin *cōnsēnsus* > (“agreement, > accordance, unanimity”) [3] it does not require unanimity IMHO. > While there are different definitions for consensus - as you point out yourself, one of the definitions is certainly a synonym for uninamity - and that's how I personally found it commonly used throughout my life. Regardless, it certainly implies no strong disagreement from those in the minority - which is not the case here. > The RFC process establishes a consensus when 2/3 of the voters agree, > which is currently the case. > As the author of that RFC, I can tell you with complete confidence that deprecations were not in the intended scope of that process. It's quite evident from the language of the Voting RFC itself: "Given that changes to languages (as opposed to changes to apps or even frameworks) are for the most part irreversible - the purpose of the vote is to ensure that there's strong support for the proposed feature." If the bar to remove a feature is identical to introducing it - it's hardly irreversible. The current behavior was never ever intended. It wasn't even supposed to be used for deprecations - but for new features. An argument could be made that this isn't a large enough consensus - > something I don't agree with - however, at the time of writing this, all > the deprecations even pass a 3/4 consensus [4]. > I think there are at least two issues that in a healthy environment would be needed: - A clear, tangible benefit to the deprecation. Having another way of doing something certainly does not constitute a clear, tangible benefit to removing a feature. This should be a pre-requisite for a deprecation. In the past it was an obvious, implicit requirement - but that's from the days where we weren't as 'litigative', so it may make sense to explicitly point it out for the future. - A much stronger consensus, that prevents the tyranny of the majority in such cases. Whether it should be 100% or 95% - but it certainly shouldn't be 2/3 or even 3/4 - and should put into affect the notion that 'changes to the language are for the most part irreversible' - which was a fundamental tenet of the Voting RFC. Zeev
Re: [PHP-DEV] Re: hebrevc() and other 'contentious' 7.4 proposed deprecations
On Tue, 16 Jul 2019 at 16:18, Zeev Suraski wrote: > Given apparently nobody has paid any attention to this email (both in terms > of my support of deprecating hebrevc(), and my request to reconsider > supporting proposals with substantial numbers of 'nay' voters) - I'm > resending it one more time for consideration: > > On Wed, Jul 10, 2019 at 2:33 PM wrote: > > > Two separate topics on this message: > > > > > > > > First – I wanted to point out that my fierce defense of the hebrev() > > function does not in fact extend to hebrevc(). As much as I think the > RFC > > was really wrong about hebrev(), and we got scarily close to deprecating > a > > functionality that – while somewhat esoteric – can be extremely useful > > and cannot be easily replicated in any way – I have to say that I think > > the RFC is pretty much correct on hebrevc(). I don't think it's very > > plausible hebrevc() is still in use today – and even if we're missing > > something and it is – it can be implemented in a one liner with 100.00% > > compatibility. While I don't think it brings much value to deprecate it > – > > perhaps sending the message that you shouldn't be using it for HTML bears > > *some* level of value. I voted in favor. > > > > > > > > Now, with that said – I would *really* encourage everyone who voted on > > this RFC (as well as ones who haven't) to take a look at what I would > call > > the 'contentious votes' in there. In a nutshell, votes with a > substantial > > amount of people voting against the deprecation. If you voted 'yes' for > > one of these – please consider, for a moment, whether your position on it > > is "It's evil, I really think we're better off without it" or whether > it's > > more of a "I don't think it's very useful". If it's the former – by all > > means, keep your vote. But if it's the latter – please consider the > > possibility that the fact that a substantial number of people feel > strongly > > enough about keeping it to vote against the deprecation (and let's admit > it > > – against the odds), may mean it is, in fact, useful – even if you don't > > find it useful yourself. > > > > > > > > While we can argue whether consensus-based voting makes sense for votes > in > > general, I think it's tenfold more important when dealing with > > deprecations. If there's a substantial minority that thinks a feature is > > still useful – we should keep it – unless there's a real tangible cost > > associated with keeping it. For most of the proposed deprecations – that > > cost is simply not there. > > > > > > > > For reference, this is what consensus looks like: > > > > https://www.dropbox.com/s/asfgt98rss3xyw2/consensus.PNG?dl=0 > > > > https://www.dropbox.com/s/iia7ua4xh6bihe3/consensus2.PNG?dl=0 > > > > > > > > And this is what it doesn't look like: > > > > https://www.dropbox.com/s/56jdl2v1lpxba49/no-consensus.PNG?dl=0 > > > > https://www.dropbox.com/s/hj8jozuun7a4w42/no-consensus2.PNG?dl=0 > > > > > > > > To connect with the first point – the hebrevc() vote certainly looks a > > lot more like the latter than the former, but I do believe it's mostly > > related to confusion with hebrev() and as the author of both – I feel > > comfortable supporting its removal :) > > > > > > > > Thanks for your consideration, > > > > > > > > Zeev > > > Hello Zeev, First of all it seems that you've mixed up your consensus2 and no-consesus2 files as they currently show the opposite of what you want to convey, I think. Secondly the word you are looking for here is "unanimity"/"unanimous" as per the Cambridge dictionary [1]: > *If a group of people are unanimous, they all agree about one particular > matter or vote the same way, and if a decision or judgment is unanimous, it > is formed or supported by everyone in a group* As consensus means, also from the Cambridge dictionary [2]: > *a generally accepted opinion or decision among a group of people* > Now unanimity implies consensus however not having a unanimous vote does not mean there is no consensus. Moreover, even though "consensus" does come from the Latin *cōnsēnsus* (“agreement, accordance, unanimity”) [3] it does not require unanimity IMHO. The RFC process establishes a consensus when 2/3 of the voters agree, which is currently the case. An argument could be made that this isn't a large enough consensus - something I don't agree with - however, at the time of writing this, all the deprecations even pass a 3/4 consensus [4]. Best regards George P. Banyard [1] https://dictionary.cambridge.org/dictionary/english/unanimous [2] https://dictionary.cambridge.org/dictionary/english/consensus [3] https://en.wiktionary.org/wiki/consensus [4] https://php-rfc-watch.beberlei.de/
[PHP-DEV] Re: hebrevc() and other 'contentious' 7.4 proposed deprecations
Given apparently nobody has paid any attention to this email (both in terms of my support of deprecating hebrevc(), and my request to reconsider supporting proposals with substantial numbers of 'nay' voters) - I'm resending it one more time for consideration: On Wed, Jul 10, 2019 at 2:33 PM wrote: > Two separate topics on this message: > > > > First – I wanted to point out that my fierce defense of the hebrev() > function does not in fact extend to hebrevc(). As much as I think the RFC > was really wrong about hebrev(), and we got scarily close to deprecating a > functionality that – while somewhat esoteric – can be extremely useful > and cannot be easily replicated in any way – I have to say that I think > the RFC is pretty much correct on hebrevc(). I don't think it's very > plausible hebrevc() is still in use today – and even if we're missing > something and it is – it can be implemented in a one liner with 100.00% > compatibility. While I don't think it brings much value to deprecate it – > perhaps sending the message that you shouldn't be using it for HTML bears > *some* level of value. I voted in favor. > > > > Now, with that said – I would *really* encourage everyone who voted on > this RFC (as well as ones who haven't) to take a look at what I would call > the 'contentious votes' in there. In a nutshell, votes with a substantial > amount of people voting against the deprecation. If you voted 'yes' for > one of these – please consider, for a moment, whether your position on it > is "It's evil, I really think we're better off without it" or whether it's > more of a "I don't think it's very useful". If it's the former – by all > means, keep your vote. But if it's the latter – please consider the > possibility that the fact that a substantial number of people feel strongly > enough about keeping it to vote against the deprecation (and let's admit it > – against the odds), may mean it is, in fact, useful – even if you don't > find it useful yourself. > > > > While we can argue whether consensus-based voting makes sense for votes in > general, I think it's tenfold more important when dealing with > deprecations. If there's a substantial minority that thinks a feature is > still useful – we should keep it – unless there's a real tangible cost > associated with keeping it. For most of the proposed deprecations – that > cost is simply not there. > > > > For reference, this is what consensus looks like: > > https://www.dropbox.com/s/asfgt98rss3xyw2/consensus.PNG?dl=0 > > https://www.dropbox.com/s/iia7ua4xh6bihe3/consensus2.PNG?dl=0 > > > > And this is what it doesn't look like: > > https://www.dropbox.com/s/56jdl2v1lpxba49/no-consensus.PNG?dl=0 > > https://www.dropbox.com/s/hj8jozuun7a4w42/no-consensus2.PNG?dl=0 > > > > To connect with the first point – the hebrevc() vote certainly looks a > lot more like the latter than the former, but I do believe it's mostly > related to confusion with hebrev() and as the author of both – I feel > comfortable supporting its removal :) > > > > Thanks for your consideration, > > > > Zeev >
Re: [PHP-DEV] Stop replacing dots with underscores in query, post and cookie parameters for PHP 8?
On Tue, Jul 16, 2019 at 5:34 AM Bishop Bettini wrote: > On Tue, Jul 16, 2019 at 3:51 AM Nikita Popov wrote: > > > On Tue, Jul 16, 2019 at 3:40 AM Arnold Daniels < > > arnold.adaniels...@gmail.com> > > wrote: > > > > > Hi, > > > > > > PHP replaces dots with underscores for $_GET, $_POST and $_COOKIE. This > > > behavior once made sense because of Register globals. The explanation > in > > > the manual also still implies that query and post parameters are > > converted > > > to variables (see > > > > > > https://php.net/manual/en/language.variables.external.php#language.variables.external.dot-in-names > > ). > > > Register globals has been removed since 5.4.0 and thus this behavior > > serves > > > little purpose. > > > > > > I think it would be good to remove the conversion in PHP 8, as it's a > > > general cause of confusion and annoyance for anyone who comes across > it. > > > > > > Is there a good reason to keep this behavior in PHP 8? > > > > > > > This has been discussed a few times already, and I think that everyone > > agrees that this behavior should go, but not necessarily on the migration > > path. There is an RFC here: > > https://wiki.php.net/rfc/on_demand_name_mangling > > I think that the latest version of that RFC, that basically proposes to > > drop the behavior and tell people to use a polyfill is fine. > > > > I've readied the proposal for formal discussion. As proposed: > >- PHP 8.0 will no longer mangle variable names in any super-global. >- The changelog will recommend auditing super-global access for mangled >names, and replacing with the actual variable name. >- No INI settings will engage the behavior. >- No warnings or notices will be emitted. >- A polyfill will be made available to emulate that original behavior. >- Applications requiring name mangling shall invoke the polyfill during >bootstrap phase. > > https://wiki.php.net/rfc/on_demand_name_mangling I think it looks good and well thought-through. The only thing I'd add is having the userland polyfill function implementation available/referenced in the Upgrade notes, so that folks can get it without Composer (in addition of having it available in Composer). I suspect the ones who'd actually won't to use it are quite likely to not be Composer users. Zeev
Re: [PHP-DEV] Stop replacing dots with underscores in query, post and cookie parameters for PHP 8?
On Tue, Jul 16, 2019 at 3:51 AM Nikita Popov wrote: > On Tue, Jul 16, 2019 at 3:40 AM Arnold Daniels < > arnold.adaniels...@gmail.com> > wrote: > > > Hi, > > > > PHP replaces dots with underscores for $_GET, $_POST and $_COOKIE. This > > behavior once made sense because of Register globals. The explanation in > > the manual also still implies that query and post parameters are > converted > > to variables (see > > > https://php.net/manual/en/language.variables.external.php#language.variables.external.dot-in-names > ). > > Register globals has been removed since 5.4.0 and thus this behavior > serves > > little purpose. > > > > I think it would be good to remove the conversion in PHP 8, as it's a > > general cause of confusion and annoyance for anyone who comes across it. > > > > Is there a good reason to keep this behavior in PHP 8? > > > > This has been discussed a few times already, and I think that everyone > agrees that this behavior should go, but not necessarily on the migration > path. There is an RFC here: > https://wiki.php.net/rfc/on_demand_name_mangling > I think that the latest version of that RFC, that basically proposes to > drop the behavior and tell people to use a polyfill is fine. > I've readied the proposal for formal discussion. As proposed: - PHP 8.0 will no longer mangle variable names in any super-global. - The changelog will recommend auditing super-global access for mangled names, and replacing with the actual variable name. - No INI settings will engage the behavior. - No warnings or notices will be emitted. - A polyfill will be made available to emulate that original behavior. - Applications requiring name mangling shall invoke the polyfill during bootstrap phase. https://wiki.php.net/rfc/on_demand_name_mangling
Re: [PHP-DEV] Stop replacing dots with underscores in query, post and cookie parameters for PHP 8?
On Tue, Jul 16, 2019 at 3:40 AM Arnold Daniels wrote: > Hi, > > PHP replaces dots with underscores for $_GET, $_POST and $_COOKIE. This > behavior once made sense because of Register globals. The explanation in > the manual also still implies that query and post parameters are converted > to variables (see > https://php.net/manual/en/language.variables.external.php#language.variables.external.dot-in-names). > Register globals has been removed since 5.4.0 and thus this behavior serves > little purpose. > > I think it would be good to remove the conversion in PHP 8, as it's a > general cause of confusion and annoyance for anyone who comes across it. > > Is there a good reason to keep this behavior in PHP 8? > This has been discussed a few times already, and I think that everyone agrees that this behavior should go, but not necessarily on the migration path. There is an RFC here: https://wiki.php.net/rfc/on_demand_name_mangling I think that the latest version of that RFC, that basically proposes to drop the behavior and tell people to use a polyfill is fine. Nikita
Re: [PHP-DEV] Stop replacing dots with underscores in query, post and cookie parameters for PHP 8?
On Tue, Jul 16, 2019 at 4:39 AM Sara Golemon wrote: > > On Mon, Jul 15, 2019 at 8:39 PM Arnold Daniels > wrote: > > PHP replaces dots with underscores for $_GET, $_POST and $_COOKIE. > > This behavior once made sense because of Register globals. > > The explanation in the manual also still implies that query and > > post parameters are converted to variables > > (see > https://php.net/manual/en/language.variables.external.php#language.variables.external.dot-in-names > ). > > Register globals has been removed since 5.4.0 and thus this behavior > serves little purpose. > > > > I think it would be good to remove the conversion in PHP 8, as it's a > general cause of confusion and annoyance for anyone who comes across it. > > > > Is there a good reason to keep this behavior in PHP 8? > > > IMO, we can safely kill this. If anyone needs this behavior preserved, it > can be mimicked with half a dozen lines of PHP, or heck we can include a > function to call. I will, however, be very surprised if anyone misses this > by now. > > -Sara Indeed, it seems that people are rather strugling to work around the current behavior (and have been for years)... Some examples: - https://bugs.php.net/bug.php?id=4 - https://stackoverflow.com/questions/68651/get-php-to-stop-replacing-characters-in-get-or-post-arrays - https://github.com/symfony/symfony/issues/9009 - https://github.com/api-platform/core/issues/509 - https://github.com/api-platform/core/blob/v2.4.5/src/Util/RequestParser.php -- Guilliam Xavier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
