Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
2015.03.19. 18:40 ezt írta ("Dan Ackroyd" ):
>
> On 19 March 2015 at 17:14, François Laupretre wrote:
>
> > As you may have noticed if you had a look at the RFC or twitter, I have
decided to follow people's suggestion.
> > Please note that the switch from E_DEPRECATED to fatal error won't
require any new RFC/discussion/vote
> > as the fatal error is considered as approved. I just introduce an
E_DEPRECATED phase for 7.0.
>
> What. The. Fuck.
>
> You edited the RFC after the voting had closed? You are not allowed to
> edit an RFC after the voting has occurred.
>
> I don't think we have any rules in place to deal with this; I don't
> think anyone anticipated that anyone would actually try to do this. We
> obviously need an explicit rule for this, but that can wait until 7.0
> is closer to shipping, and we can contemplate RFC rules at leisure.
>
> For now, please revert the changes your made to the RFC after it had
> been closed. And whoever has the power to remove karma, please take
> the power to edit RFCs away from Francois once that has been done.
>
> > Array to string conversion will raise E_DEPRECATED in 7.0, and, then,
fatal error in 7.1 or 7.2.
>
> You are being dumb here as well. We try to avoid breaking code in
> point releases. This BC break can only be done at a major version.
>
> E_DEPRECATED is not a magic bullet - that makes all BC problems go
> away. The reason why we voted on it for 7.0 is that it is a major
> break, but one that is acceptable to be done at a major version. It
> would not be acceptable to change the behaviour in a minor version.
>
> cheers
> Dan
>
We have no reason to think that this wasn't just a honest mistake, so there
is no reason for any sactions.
Personally I agree, we either remove it in 7.0(without prior deprecation as
we voted no for 5.7) or deprecate it in 7.0 and remove in the next major
version.
Everything else is a PITA and against our release process rfc.
Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
On Fri, Mar 20, 2015 at 1:21 PM, François Laupretre wrote: > May I also add that it is not the first time people raise concerns about RFCs > when vote starts. On different occasions, it was clear that most had not read > the RFC before the vote was announced. I even have two RFCs which were > planned for 7.0 and won't be in because I had to stop the vote and restart a > discussion. When we have short timelines, as for 7.0, it's a real problem > because restarting a discussion easily adds one month to the approval > process. Actually, I don't know if, in this case, I shouldn't reply that the > discussion is over and that it's just too late to wake up. The problem is not the RFC process but us accepting idealistic timelnes. It is why I did not vote (for the ones that did not respect the RFC process) or no for the ones I totally disagree with. But this is off topic imho, we took these decisions now we have to work with that. In any case, one thing has to end, the playing with the rules. Discussions must happen for at least two weeks before a RFC goes to vote, mail must be sent to announce each phase. And last but not least, editing a RFC during or after the votes in a way that it changes what people votes for or against is not something I want to see. We have to solve this issue. Learning by doing :) Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Question/comment about the Array to String conversion RFC
May I also add that it is not the first time people raise concerns about RFCs when vote starts. On different occasions, it was clear that most had not read the RFC before the vote was announced. I even have two RFCs which were planned for 7.0 and won't be in because I had to stop the vote and restart a discussion. When we have short timelines, as for 7.0, it's a real problem because restarting a discussion easily adds one month to the approval process. Actually, I don't know if, in this case, I shouldn't reply that the discussion is over and that it's just too late to wake up. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Question/comment about the Array to String conversion RFC
> De : Dan Ackroyd [mailto:dan...@basereality.com] > > On 19 March 2015 at 17:14, François Laupretre wrote: > > > As you may have noticed if you had a look at the RFC or twitter, I have > decided to follow people's suggestion. > > Please note that the switch from E_DEPRECATED to fatal error won't > require any new RFC/discussion/vote > > as the fatal error is considered as approved. I just introduce an > E_DEPRECATED phase for 7.0. > > What. The. Fuck. > > You edited the RFC after the voting had closed? You are not allowed to > edit an RFC after the voting has occurred. > > I don't think we have any rules in place to deal with this; I don't > think anyone anticipated that anyone would actually try to do this. We > obviously need an explicit rule for this, but that can wait until 7.0 > is closer to shipping, and we can contemplate RFC rules at leisure. > > For now, please revert the changes your made to the RFC after it had > been closed. And whoever has the power to remove karma, please take > the power to edit RFCs away from Francois once that has been done. > > > Array to string conversion will raise E_DEPRECATED in 7.0, and, then, fatal > error in 7.1 or 7.2. > > You are being dumb here as well. We try to avoid breaking code in > point releases. This BC break can only be done at a major version. OK. OK. I revert the RFC to its original version. It will raise E_RECOVERABLE_ERROR in 7.0. Before you burn me alive, here's what happened : I was in Africa during the last 3 weeks, and didn't have any way to post to the list. I just had one hour of internet access during all this time and wanted to use it to close the vote, but I saw Zeev's and Julien's comments asking for a deprecate phase in 7.0, and thought that, if there was a rule, I had to respect it. I am not as dumb as you may think, I know BC breaks must be introduced in major versions, but the requests to do so were coming from people who are supposed to know the rules better than I. So, I added a line at the end of the RFC and sent a private message via twitter to Zeev asking him to forward the information to the list to discuss whether this change after vote was considered as acceptable or not. Unfortunately, I discovered his reply this morning saying he preferred me to do it when I would be back. That's why you discovered it today. So, I probably shouldn't have modified the RFC when I closed the vote, but there was a context. So, as it is not clear whether there's a rule saying that everything must be deprecated before being removed, I will implement the RFC exactly as it was voted. And let me apologize for the misunderstandings I have caused. Regards François I thought introducing a temporary E_DEPRECATED phase would be acceptable to everyone and I would have asked the list but I could not send emails from where I was during the last 2 weeks. I just had web access during 1 hour, read Zeev's and Julien's comments, added one line in the RFC, and then sent a twitter message to Zeev asking him to forward the change to the list so that it could be judged acceptable or not. Unfortunately, was in Africa during the last 2 weekssatisfy everyone but it seems it is not the case. Now, what should I say when people who are supposed to know the process better than me ask to delay the BC break to 7.1 or 7.2 ? > > cheers > Dan > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
On Fri, Mar 20, 2015 at 5:04 AM, Nikita Popov wrote: > On Thu, Mar 19, 2015 at 6:49 PM, Zeev Suraski wrote: > >> > On 19 במרץ 2015, at 19:40, Dan Ackroyd wrote: >> > >> > You are being dumb here as well. We try to avoid breaking code in >> > point releases. This BC break can only be done at a major version. >> >> Technically, we're not allowed to move from from a working feature into a >> removed one without a deprecation phase. >> > > I don't think this is true. There is no requirement for us to deprecate > something before we remove it. Deprecation is a courtesy to our users in > cases where a heavily used feature is being dropped. I think we do not need to argue about the impact of having something generating a fatal error all of a sudden in 7.1. Or am I missing something? :) > Realistically most people consider E_NOTICE to be a higher error level than > E_DEPRECATED. If somebody is willing to suppress the notices this currently > generates, chances are very high that deprecations are suppressed as well. > I don't see any release process issues with dropping this without > deprecation. (But I'm still -1 on the change, because I don't see why we'd > suddenly want to change this one relatively unimportant notice to be fatal > while leaving everything else alone.) Same, if anything doing fatal then it has to be done in 7.0. Also I have to agree with Zeev on that, a warning or deprecation notice should be enough. I know it is not what many users want, to clean up such things, but we decided not to have a 5.7 to prepare such removals, let act accordingly. cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
Hi! >> As you may have noticed if you had a look at the RFC or twitter, I have >> decided to follow people's suggestion. >> Please note that the switch from E_DEPRECATED to fatal error won't require >> any new RFC/discussion/vote >> as the fatal error is considered as approved. I just introduce an >> E_DEPRECATED phase for 7.0. > > What. The. Fuck. Let's tone down here. While editing RFC anytime after the vote has started without advanced notice is unacceptable and should not be done, I don't think it's anything but a honest mistake. Of course, even more unacceptable is to change it when voting results are in. But let's not create more drama of it then necessary. Wikipedia has a rule that says "assume good faith" (yes, I know in practice it is more complicated :) - I think we could use more invocation of this rule here too. It looks like the RFC author has not really decided what he wants to do. If he doesn't want to support the RFC anymore, as voted, he can just withdraw it and let somebody pick it up if willing (that's what happened to <=> RFC and scalar typing RFC, so we have precedents). Or create a new different one to supersede the old one. What not should be done of course is editing voted RFC and using that as a base for changes. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
Dan Ackroyd wrote on 19/03/2015 18:11: Rowan wrote: >you should pause, make a cup of tea, and redraft the e-mail. That was the redrafted version. And yet it still accused another contributor of "being dumb", and demanded they have access revoked. That is not a respectful or proportional response to the situation. The edits to the RFC were made two weeks ago. In Francois' defence he himself alerted the list to the changes. But the unapproved editing also meant that if there was someone else who was concerned about the BC break, they might not have raised an RFC to revert the RFC, before the cut off time for RFCs. This is one of the reasons why someone editing the text of a passed RFC is utterly unacceptable. Anyone knowledgeable enough about the process to raise such an RFC would, at worst, have expressed confusion about the validity of the edit. Note that the text of the vote remains "Yes to replace E_NOTICE with E_RECOVERABLE_ERROR, No for no change." so it's kind of obvious that's what was agreed to. There is no inline editing of the text to make it look like this was always the case, and the wiki provides full history to anyone who cares to check. Again, I agree that editing the RFC was wrong here, but I think a "please don't do this again" would have been sufficient. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
Hi Zeev, On 19 March 2015 at 17:49, Zeev Suraski wrote: > Technically, we're not allowed to move from from a working feature into a > removed one without a deprecation phase. Please can you point me to where this is written down? Please also show me where it says that this rule cannot be over-ridden by an RFC, which is our path of changing rules. The point of deprecating things is to smooth the path of fixing issues. It allows people to detect in their codebase places where there is code that is currently working fine without error, that is going to break in a future version of PHP. Any array to string conversion is already detectable as it emits a 'notice'. It does not need an intermediate step of changing the notice to being a deprecation warning; that provides no benefit to users. Rowan wrote: > you should pause, make a cup of tea, and redraft the e-mail. That was the redrafted version. The edits to the RFC were made two weeks ago. In Francois' defence he himself alerted the list to the changes. But the unapproved editing also meant that if there was someone else who was concerned about the BC break, they might not have raised an RFC to revert the RFC, before the cut off time for RFCs. This is one of the reasons why someone editing the text of a passed RFC is utterly unacceptable. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
On Thu, Mar 19, 2015 at 6:49 PM, Zeev Suraski wrote: > > On 19 במרץ 2015, at 19:40, Dan Ackroyd wrote: > > > > You are being dumb here as well. We try to avoid breaking code in > > point releases. This BC break can only be done at a major version. > > Technically, we're not allowed to move from from a working feature into a > removed one without a deprecation phase. > I don't think this is true. There is no requirement for us to deprecate something before we remove it. Deprecation is a courtesy to our users in cases where a heavily used feature is being dropped. Realistically most people consider E_NOTICE to be a higher error level than E_DEPRECATED. If somebody is willing to suppress the notices this currently generates, chances are very high that deprecations are suppressed as well. I don't see any release process issues with dropping this without deprecation. (But I'm still -1 on the change, because I don't see why we'd suddenly want to change this one relatively unimportant notice to be fatal while leaving everything else alone.) Nikita
Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
On Thu, Mar 19, 2015 at 11:49 AM, Zeev Suraski wrote: >> On 19 במרץ 2015, at 19:40, Dan Ackroyd wrote: >> >> You are being dumb here as well. We try to avoid breaking code in >> point releases. This BC break can only be done at a major version. > > Technically, we're not allowed to move from from a working feature into a > removed one without a deprecation phase. We have historically broke BC a lot without deprecation. I also know of no such rule in our written RFCs. If historical behavior says otherwise, and we don't have this written down anywhere... how can you claim this is a rule? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
On Thu, Mar 19, 2015 at 1:40 PM, Dan Ackroyd wrote: > On 19 March 2015 at 17:14, François Laupretre wrote: > >> As you may have noticed if you had a look at the RFC or twitter, I have >> decided to follow people's suggestion. >> Please note that the switch from E_DEPRECATED to fatal error won't require >> any new RFC/discussion/vote >> as the fatal error is considered as approved. I just introduce an >> E_DEPRECATED phase for 7.0. > > You edited the RFC after the voting had closed? You are not allowed to > edit an RFC after the voting has occurred. > Agreed. I hereby change my vote from 'Yes' to 'No' in protest of this action. > For now, please revert the changes your made to the RFC after it had > been closed. > Please. If we need to change the schedule, let that be a separate RFC. > And whoever has the power to remove karma, please take > the power to edit RFCs away from Francois once that has been done. > Now that's a bit heavy-handed. Let's call this a slap on the wrist and move on. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
Dan Ackroyd wrote on 19/03/2015 17:40: On 19 March 2015 at 17:14, François Laupretre wrote: As you may have noticed if you had a look at the RFC or twitter, I have decided to follow people's suggestion. Please note that the switch from E_DEPRECATED to fatal error won't require any new RFC/discussion/vote as the fatal error is considered as approved. I just introduce an E_DEPRECATED phase for 7.0. What. The. Fuck. I agree with the substance of what you wrote, but would like to appeal for some civility and Assumption of Good Faith. When you find yourself typing the word "fuck" on a public mailing list, you should pause, make a cup of tea, and redraft the e-mail. You edited the RFC after the voting had closed? You are not allowed to edit an RFC after the voting has occurred. Yes, this was not a good idea. The RFC as accepted was for a fatal error; a change to E_DEPRECATED would require a new RFC, or at least a supplementary vote. I don't think we have any rules in place to deal with this; I don't think anyone anticipated that anyone would actually try to do this. We obviously need an explicit rule for this, but that can wait until 7.0 is closer to shipping, and we can contemplate RFC rules at leisure. For now, please revert the changes your made to the RFC after it had been closed. And whoever has the power to remove karma, please take the power to edit RFCs away from Francois once that has been done. Let's keep this in perspective - no permanent harm has been done, anyone can revert the page, and Francois can learn from the mistake. These two paragraphs can be boiled down to "Can you or someone revert it please, to reflect the text as accepted." Array to string conversion will raise E_DEPRECATED in 7.0, and, then, fatal error in 7.1 or 7.2. You are being dumb here as well. This sentence is simply unnecessary. We try to avoid breaking code in point releases. This BC break can only be done at a major version. E_DEPRECATED is not a magic bullet - that makes all BC problems go away. The reason why we voted on it for 7.0 is that it is a major break, but one that is acceptable to be done at a major version. It would not be acceptable to change the behaviour in a minor version. This point is valid. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
> On 19 במרץ 2015, at 19:40, Dan Ackroyd wrote: > > You are being dumb here as well. We try to avoid breaking code in > point releases. This BC break can only be done at a major version. Technically, we're not allowed to move from from a working feature into a removed one without a deprecation phase. So why I agree with you it's a problem to just edit the RFC without getting a wide OK for it after a vote has concluded, what's much worse is that so many people voted Yes for an RFC that violated that principle, and not s single person was bothered to even reply to a query about it. Note that contrary to what you said, a vote would have been equally required regardless of whether we follow our deprecation process, or violate it for no good reason. You're right we won't be able to move to remove it in 7.x - but it's exactly at the same level that we mustn't move to an error in 7.0. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
On 19 March 2015 at 17:14, François Laupretre wrote: > As you may have noticed if you had a look at the RFC or twitter, I have > decided to follow people's suggestion. > Please note that the switch from E_DEPRECATED to fatal error won't require > any new RFC/discussion/vote > as the fatal error is considered as approved. I just introduce an > E_DEPRECATED phase for 7.0. What. The. Fuck. You edited the RFC after the voting had closed? You are not allowed to edit an RFC after the voting has occurred. I don't think we have any rules in place to deal with this; I don't think anyone anticipated that anyone would actually try to do this. We obviously need an explicit rule for this, but that can wait until 7.0 is closer to shipping, and we can contemplate RFC rules at leisure. For now, please revert the changes your made to the RFC after it had been closed. And whoever has the power to remove karma, please take the power to edit RFCs away from Francois once that has been done. > Array to string conversion will raise E_DEPRECATED in 7.0, and, then, fatal > error in 7.1 or 7.2. You are being dumb here as well. We try to avoid breaking code in point releases. This BC break can only be done at a major version. E_DEPRECATED is not a magic bullet - that makes all BC problems go away. The reason why we voted on it for 7.0 is that it is a major break, but one that is acceptable to be done at a major version. It would not be acceptable to change the behaviour in a minor version. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Question/comment about the Array to String conversion RFC
On Mar 20, 2015 12:14 AM, "François Laupretre" wrote: > > > De : Zeev Suraski [mailto:z...@zend.com] > > > > https://wiki.php.net/rfc/array-to-string (which I voted yes to) deviates > > from our guidelines of deprecating features first, and removing them > > later; It’s addressed in the RFC – but I’m a bit worried that this opens > > the door to jumping from any sort of notice/warning into errors or removed > > features without any deprecation phase. > > > > In comparison, in Nikita’s RFC for removing E_STRICT – there aren’t any > > proposed ‘jumps’ to E_RECOVERABLE_ERROR that don’t first go through > > E_DEPRECATED. > > > > Should we not go through this deprecation cycle, even if may feel anxious > > to get rid of this behavior? > > Sorry for the delay but I could not send emails during the last 3 weeks. > > As you may have noticed if you had a look at the RFC or twitter, I have decided to follow people's suggestion. Array to string conversion will raise E_DEPRECATED in 7.0, and, then, fatal error in 7.1 or 7.2. Hmm.. Sorry but no. I really do not think we can do this, this will bring a major BC in 7.1+ and we do not allow BC but in extreme cases. > Please note that the switch from E_DEPRECATED to fatal error won't require any new RFC/discussion/vote as the fatal error is considered as approved. I just introduce an E_DEPRECATED phase for 7.0. Well, if it is, do it in 7.0. But changing that all of a sudden and making it fatal in 7.1+ is an extremely bad idea :) > Regards > > François > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
RE: [PHP-DEV] Question/comment about the Array to String conversion RFC
> De : Zeev Suraski [mailto:z...@zend.com] > > https://wiki.php.net/rfc/array-to-string (which I voted yes to) deviates > from our guidelines of deprecating features first, and removing them > later; It’s addressed in the RFC – but I’m a bit worried that this opens > the door to jumping from any sort of notice/warning into errors or removed > features without any deprecation phase. > > In comparison, in Nikita’s RFC for removing E_STRICT – there aren’t any > proposed ‘jumps’ to E_RECOVERABLE_ERROR that don’t first go through > E_DEPRECATED. > > Should we not go through this deprecation cycle, even if may feel anxious > to get rid of this behavior? Sorry for the delay but I could not send emails during the last 3 weeks. As you may have noticed if you had a look at the RFC or twitter, I have decided to follow people's suggestion. Array to string conversion will raise E_DEPRECATED in 7.0, and, then, fatal error in 7.1 or 7.2. Please note that the switch from E_DEPRECATED to fatal error won't require any new RFC/discussion/vote as the fatal error is considered as approved. I just introduce an E_DEPRECATED phase for 7.0. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
Hi all, On Tue, Mar 3, 2015 at 2:30 AM, Julien Pauli wrote: > On Mon, Mar 2, 2015 at 4:10 PM, Patrick ALLAERT > wrote: > > > Le lun. 2 mars 2015 à 15:24, Zeev Suraski a écrit : > > > > > All, > > > > > > > > > > > > https://wiki.php.net/rfc/array-to-string (which I voted yes to) > deviates > > > from our guidelines of deprecating features first, and removing them > > > later; It’s addressed in the RFC – but I’m a bit worried that this > opens > > > the door to jumping from any sort of notice/warning into errors or > > removed > > > features without any deprecation phase. > > > > > > > > > > > > In comparison, in Nikita’s RFC for removing E_STRICT – there aren’t any > > > proposed ‘jumps’ to E_RECOVERABLE_ERROR that don’t first go through > > > E_DEPRECATED. > > > > > > > > > > > > Should we not go through this deprecation cycle, even if may feel > anxious > > > to get rid of this behavior? > > > > > > > I'm all for deprecating before it gets removed (especially since I voted > > "no" to that). > > > > > Same to me, I voted no because we're gonna break something which is not > "that bad" and turn it to a clear breakage in one step. > I would prefer we E_DEPRACTE before E_ERRORing , we can deprecate in 7.0 > and remove in 7.1 or 7.2 or whatever. > We chose not to have a 5.7 for deprecation purpose only (or not), but this > doesn't mean 7.0 shouldn't deprecate anything IMO. > I had same idea, but I voted yes. Conversion from array to string is a bug should be fixed anyway. There may be code that checks invalid "Array" string, though. I think changing E_NOTICE to E_DEPRECATED/E_STRICT is good idea. E_DEPRECATED/E_STRICT then E_NOTICE/E_WARNING/E_ERROR is better path. Users should be able to catch bugs with E_DEPRECATED/E_STRICT also. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
On 2 March 2015 at 14:24, Zeev Suraski wrote: > https://wiki.php.net/rfc/array-to-string (which I voted yes to) deviates > from our guidelines of deprecating features first, and removing them > later; > > Should we not go through this deprecation cycle, even if may feel anxious > to get rid of this behavior? I don't think it's required. The purpose of deprecation notices is to allow people to detect issues in their code that is currently working as they want, and without giving any warning messages. This allows them to estimate how much effort it would be to upgrade to a newer version of PHP, one in which the behaviour is no longer allowed, without actually having to refactor all the code to find out. In this case, the code already produces a notice that says the behaviour is not completely ok, so people are able to detect where array to string conversion is happening. Having an intermediate step of E_DEPRECATED notice would not affect the amount of code that they would need to change nor will it make it significantly easier to detect places in their code where this behaviour is occurring. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
On Mar 3, 2015 4:31 AM, "Julien Pauli" wrote: > Same to me, I voted no because we're gonna break something which is not > "that bad" and turn it to a clear breakage in one step. > I would prefer we E_DEPRACTE before E_ERRORing , we can deprecate in 7.0 > and remove in 7.1 or 7.2 or whatever. > We chose not to have a 5.7 for deprecation purpose only (or not), but this > doesn't mean 7.0 shouldn't deprecate anything IMO. We should not remotely consider to remove things like that in 7.x, ever. This will simply make applications migration to latest 7 series a nightmare. And yes, I do consider it was a strategical mistake to have rejected 5.7 for this exact reason. Same for the random features freeze deadline, we end up now with so many decisions to take on a hurry, while many of them are critical for 7. Both should be reconsidered. I do not think that will affect the final release date for 7.
Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
On Mon, Mar 2, 2015 at 4:10 PM, Patrick ALLAERT wrote: > Le lun. 2 mars 2015 à 15:24, Zeev Suraski a écrit : > > > All, > > > > > > > > https://wiki.php.net/rfc/array-to-string (which I voted yes to) deviates > > from our guidelines of deprecating features first, and removing them > > later; It’s addressed in the RFC – but I’m a bit worried that this opens > > the door to jumping from any sort of notice/warning into errors or > removed > > features without any deprecation phase. > > > > > > > > In comparison, in Nikita’s RFC for removing E_STRICT – there aren’t any > > proposed ‘jumps’ to E_RECOVERABLE_ERROR that don’t first go through > > E_DEPRECATED. > > > > > > > > Should we not go through this deprecation cycle, even if may feel anxious > > to get rid of this behavior? > > > > I'm all for deprecating before it gets removed (especially since I voted > "no" to that). > > Same to me, I voted no because we're gonna break something which is not "that bad" and turn it to a clear breakage in one step. I would prefer we E_DEPRACTE before E_ERRORing , we can deprecate in 7.0 and remove in 7.1 or 7.2 or whatever. We chose not to have a 5.7 for deprecation purpose only (or not), but this doesn't mean 7.0 shouldn't deprecate anything IMO. Julien.Pauli
Re: [PHP-DEV] Question/comment about the Array to String conversion RFC
Le lun. 2 mars 2015 à 15:24, Zeev Suraski a écrit : > All, > > > > https://wiki.php.net/rfc/array-to-string (which I voted yes to) deviates > from our guidelines of deprecating features first, and removing them > later; It’s addressed in the RFC – but I’m a bit worried that this opens > the door to jumping from any sort of notice/warning into errors or removed > features without any deprecation phase. > > > > In comparison, in Nikita’s RFC for removing E_STRICT – there aren’t any > proposed ‘jumps’ to E_RECOVERABLE_ERROR that don’t first go through > E_DEPRECATED. > > > > Should we not go through this deprecation cycle, even if may feel anxious > to get rid of this behavior? > I'm all for deprecating before it gets removed (especially since I voted "no" to that). Patrick
