[PHP-DEV] Re: [VOTE][RFC] Access to aliases definition by reflection
Hi Internals, It is two weeks I opened the RFC voting. Even the responses are negative for now, I would like to remind you to vote. Because the amount of votes is low, I hope I didn't do some mistake in RFC procedure. Thank you, Milo Dne 26.11.2014 10:48, Miloslav Hůla napsal(a): Good morning internals, after several weeks, I'm opening voting process for the RFC https://wiki.php.net/rfc/aliases_by_reflection. Thank you, Milo -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On the road to PHP 5.7 , or not ?
On Fri, 12 Dec 2014, Ferenc Kovacs wrote: On Fri, Dec 12, 2014 at 3:34 PM, Derick Rethans der...@php.net wrote: On Fri, 12 Dec 2014, Julien Pauli wrote: So the main question is : *What version will we release next year ?* Will we have a PHP 5.7, or jump directly to a 7.0 ? Don't forget, that if we go for a 5.7 , then we won't have a 7.0 at least one year later. We have accepted the timeline for 7, so we need to stick to that: https://wiki.php.net/rfc/php7timeline#vote So that means no 5.7. This rfc was specific to php7, and while you are right that with that we do have an approved timelime for php7, but this doesn't say anything about 5.7 (and as far as I'm concerned, it was an intentional choice from Zeev not just something he forgot to include). Maybe it would be worthwile for you to repeat your arguments or simply link them, as I do remember that you are supporting the idea of not having any other release minor release until php7 is out of the door so the development efforts are not fragmented (which as I mentioned in my previous mail I feell it would be only a shift from 5.6.x to 5.7.0 and not fragmanting the php7 development, but you seem to disagree). Yes, I disagree. It's a time thing. Let's all work on one thing instead of *two*. Clearly you must see that there is not enough bandwidth? It will also prevent people from oh we can get this into 5.7 nonsense. It's not helpful, and it *is* fragmenting development. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On the road to PHP 5.7 , or not ?
On Sat, 13 Dec 2014, Pierre Joye wrote: On Dec 12, 2014 9:34 PM, Derick Rethans der...@php.net wrote: On Fri, 12 Dec 2014, Julien Pauli wrote: So the main question is : *What version will we release next year ?* Will we have a PHP 5.7, or jump directly to a 7.0 ? Don't forget, that if we go for a 5.7 , then we won't have a 7.0 at least one year later. We have accepted the timeline for 7, so we need to stick to that: https://wiki.php.net/rfc/php7timeline#vote I hate to say that but if we stick to rules, this rfc and its result are totally invalid and should be canceled. What a bonkers statement. Just because you don't agree it's not totally invalid. I think 34 vs 2 is a pretty solid argument for sticking to it. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
On Sun, 14 Dec 2014, George Bond wrote: If you wanted an upgrade path that was not Evil (in the sense of not introducing subtle and hard-to-diagnose bugs), could you not change the operator to be *un*associative in PHP7? That would effectively just make concrete the discouragement/deprecation that's already in the documentation, and would produce irritating but very visible errors for anyone still actually using this functionality, as well as making them alter their code in a forward-compatible way. Then if you want to think really long term, plan to implement the 'correct' associativity in the *next* major version. As long as this unassociativity turns it into a hard syntax error (ie, php -l will catch it out), I am not against this. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Add a new flag for json_encode
Ok guys, sorry, but I am giving up on it. I opened the PR in April and all the code necessary with technical implications are done and registered on the PR. I brought the topic to this email list in November as requested in the PR and almost 1 month after you guys requested me to write a RFC. I tried to create a wiki account to write the RFC 15 days ago[1] and I had no answer in create a simple wiki account. I have no idea how long it will take and how long the RFC will be on discussion, but seems the whole process will take over 1 year. Unfortunately I don't have patience enough for it. I guess I put my contribution on the project proposing the code, discussing the technical part and executing benchmarks. If you want to use it, use, but if you want to just ignore because I didn't complete all the steps fine too, just close the PR and this topic is automatically closed. I would like to contribute more with PHP core, but if this is the process to contribute with PHP, I am out. I will help other projects that give more attention and love for who wants to contribute and not making the person to worry about the bureaucratic part. Sorry. [1] http://news.php.net/php.webmaster/20312 Juan Basso On Sun, Nov 30, 2014 at 11:58 PM, Juan Basso jrba...@gmail.com wrote: I see. I thought it was some sort of simplified RFC. :) Ok, I will create a RFC regarding it. On Sun, Nov 30, 2014 at 8:49 PM, Andrea Faulds a...@ajf.me wrote: On 1 Dec 2014, at 01:48, Juan Basso jrba...@gmail.com wrote: What is ofc? I never heard about it before. Do I need to do something? “ofc” is just an abbreviation for “of course”. -- Andrea Faulds http://ajf.me/
Re: [PHP-DEV] On the road to PHP 5.7 , or not ?
On Dec 15, 2014 11:53 PM, Derick Rethans der...@php.net wrote: On Sat, 13 Dec 2014, Pierre Joye wrote: On Dec 12, 2014 9:34 PM, Derick Rethans der...@php.net wrote: On Fri, 12 Dec 2014, Julien Pauli wrote: So the main question is : *What version will we release next year ?* Will we have a PHP 5.7, or jump directly to a 7.0 ? Don't forget, that if we go for a 5.7 , then we won't have a 7.0 at least one year later. We have accepted the timeline for 7, so we need to stick to that: https://wiki.php.net/rfc/php7timeline#vote I hate to say that but if we stick to rules, this rfc and its result are totally invalid and should be canceled. What a bonkers statement. Just because you don't agree it's not totally invalid. I think 34 vs 2 is a pretty solid argument for sticking to it. Aller php7 related RFCs from there are invalid if we stick to the rules. The author asked to respect rules while systematically breaking them. And that's my point here. People voting massively yes because oh it will not happen if we don't say yes now is only bad. For that last one, even the author admit that we may not make it as described. I may propose a counter rfc or just for 5.7, did not make my mind yet. Why should I make a php7 more complete rfc? Because we agreed to make one together to propose actual choices. I was respectful enough to wait on the other author until he was ready. Nice move. So please, before you go up your horse telling me that my arguments are bad, get your facts straight, thanks. Cheers, Pierre
Re: [PHP-DEV] On the road to PHP 5.7 , or not ?
Pierre Joye wrote on 15/12/2014 17:39: I hate to say that but if we stick to rules, this rfc and its result are totally invalid and should be canceled. What a bonkers statement. Just because you don't agree it's not totally invalid. I think 34 vs 2 is a pretty solid argument for sticking to it. Aller php7 related RFCs from there are invalid if we stick to the rules. The author asked to respect rules while systematically breaking them. And that's my point here. Can you succinctly, without any personal attacks, explain which rules this RFC broke? Thanks, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
On Dec 14, 2014, at 23:50, Leon Sorokin leeon...@gmail.com wrote: On 12/14/2014 10:45 PM, Robert Williams wrote: I strongly suspect far more code would be *fixed* if the ternary operator were changed to match what other languages do. If you have 'incorrectly' functioning code today that results in passing unit tests and a correctly functioning business. Then a sudden change to the behavior of this code would necessarily result in failing unit tests and an incorrectly functioning business. What world is this that you live in where every line of code that’s written is fully unit-tested, where functional bugs in large, highly complex applications are both obvious and immediately apparent? In my world, I’ve inherited millions of lines of legacy code written seemingly to defy the possibility of unit testing, where there are large chunks of code that may run once every several years, and where many types of logic bugs are simply undetectable unless a team of auditors on the business side is double-checking every result of the code. Sure, I also have a million or two lines of newer code that is heavily unit-tested, but even that code has bugs. Given that we have this bug to begin with (and yes, it’s a bug), as well as many of the others that have worked their way into the PHP code base, it strikes me that PHP itself is written in my world, not yours. Hey, reality bites. Also, code that is thoroughly unit-tested is not the code we need to worry about for the very reasons you espouse. If the ternary behavior is changed, the one or two bugs that may be introduced in every several hundred K LOC will become immediately apparent on first test-run and probably be fixed in 30 minutes or less. It’s the crappy code that we have to worry about, the code that’s broken and no one even knows about it. In these cases, I maintain, fixing ternary would only improve the code’s functioning. -Bob -- Bob Williams SVP, Software Development Newtek Business Services, Inc. “The Small Business Authority” http://www.thesba.com/ Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any).
Re: [PHP-DEV] On the road to PHP 5.7 , or not ?
On 12 December 2014 at 23:19, Zeev Suraski z...@zend.com wrote: 3. Last (and probably least) - a 5.7 that breaks compatibility is inconsistent with our version strategy, that suggests 5.7 should be fully compatible with 5.6. Whoa — I'm not talking about breaking compatibility. I'm talking about generating deprecation warnings on things we know are going to break in PHP 7. Travelling backwards a point: 2. My position about 5.7 that's minimally different from 5.6 and just 'helps migration', is that it's practically useless. Users won't go through the headache of hopping through two versions, for some supposed unknown benefits. PHP 7 breakage is going to be fairly localized to specific areas - not so much the engine changes which barely breaks anything. So if 5.7 'breaks' the same areas that 7.0 does (keywords, warnings in the right places, etc.) - migrating to it would essentially be as painful (or painless) as migrating to 7.0. In other words, no benefits to doing this extra step from the point of view of most users. As I said, 5.7 wouldn't break anything, to my mind. The point is to provide a way for users to get a heads up on what things they need to be looking into to either migrate to PHP 7, or have a single code base that runs on both PHP 5 and 7, depending on their needs. The Python experience suggests that both of these cases _need_ to be supported, and well. Why wouldn't we — the people best placed to do so — provide the tooling to do that as part of the runtime? The strawman version of your position seems to be that users are going to just migrate to PHP 7 en masse, and that they'll be happy with their code breaking to tell them what to fix. I'm not sure there's any history in PHP or other languages that suggests that's really what will happen, and I think we're doing our users a disservice if we don't make the path to having a mixed 5/7 code base as easy as possible. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Add a new flag for json_encode
On Mon, Dec 15, 2014 at 6:16 PM, Juan Basso jrba...@gmail.com wrote: Ok guys, sorry, but I am giving up on it. I opened the PR in April and all the code necessary with technical implications are done and registered on the PR. I brought the topic to this email list in November as requested in the PR and almost 1 month after you guys requested me to write a RFC. I tried to create a wiki account to write the RFC 15 days ago[1] and I had no answer in create a simple wiki account. I have no idea how long it will take and how long the RFC will be on discussion, but seems the whole process will take over 1 year. Unfortunately I don't have patience enough for it. I guess I put my contribution on the project proposing the code, discussing the technical part and executing benchmarks. If you want to use it, use, but if you want to just ignore because I didn't complete all the steps fine too, just close the PR and this topic is automatically closed. I would like to contribute more with PHP core, but if this is the process to contribute with PHP, I am out. I will help other projects that give more attention and love for who wants to contribute and not making the person to worry about the bureaucratic part. Sorry. [1] http://news.php.net/php.webmaster/20312 Hi, I'm sorry for the negative experience, and I agree that we did a bad job handling this PR. ps: I've just replied to your mail, but I can understand if you aren't going to put more effort into getting this merged. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
[PHP-DEV] Re: [VOTE][RFC] Access to aliases definition by reflection
Miloslav Hůla: It is two weeks I opened the RFC voting. Even the responses are negative for now, I would like to remind you to vote. Because the amount of votes is low, I hope I didn't do some mistake in RFC procedure. It seems to me that it's customary to specify the voting period *in advance* (cf. other RFC currently in the voting phase[1]). Not sure, though, if it's a problem to do otherwise. [1] https://wiki.php.net/rfc#in_voting_phase -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On the road to PHP 5.7 , or not ?
On 15 December 2014 at 08:51, Derick Rethans der...@php.net wrote: Yes, I disagree. It's a time thing. Let's all work on one thing instead of *two*. Clearly you must see that there is not enough bandwidth? It will also prevent people from oh we can get this into 5.7 nonsense. It's not helpful, and it *is* fragmenting development. I'm just as cognisant of our time constraints as you are, but I still think this can work if there's a clear, written expectation (say via RFC) that 5.7 is for migration related changes only, and should not include new feature work. If we can keep this as 5.6 + some deprecation warnings, I believe that can reduce the QA/development load enough to make delivering it and 7.0 possible next year. Adam, who apparently put his optimistic pants on this morning. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
Leon Sorokin wrote on 13/12/2014 22:45: Hi guys, I was wondering if 7.0 could be the version to fix the long-standing incorrect ternary associativity bug in PHP [1]. This seems especially worthy of reconsideration since the Null Coalesce RFC has been accepted and merged [2] with the correct associativity [3]. The major version change seems like the only time to get this done in PHP. [1] https://bugs.php.net/bug.php?id=61915 [2] https://wiki.php.net/rfc/isset_ternary [3] http://news.php.net/php.internals/79584 thanks, -- Leon Sorokin Actually, thinking further on this, I'm not sure I've ever actually been affected by the associativity of ?: one way or the other. I have fallen foul of its precedence relative to concatenation, as in: echo 'hello' . false ? ' world' : ' there' . '!'; http://3v4l.org/i7cSc But I think this is the same in other languages, and not related to this bug? Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE][RFC] Access to aliases definition by reflection
On 15 Dec 2014, at 18:08, Christoph Becker cmbecke...@gmx.de wrote: Miloslav Hůla: It is two weeks I opened the RFC voting. Even the responses are negative for now, I would like to remind you to vote. Because the amount of votes is low, I hope I didn't do some mistake in RFC procedure. It seems to me that it's customary to specify the voting period *in advance* (cf. other RFC currently in the voting phase[1]). Not sure, though, if it's a problem to do otherwise. [1] https://wiki.php.net/rfc#in_voting_phase Yes, you should specify one ahead of time. Otherwise it looks like you are only closing it when convenient (e.g. extra yes vote at last minute). -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE][RFC] Access to aliases definition by reflection
Oh, thank you both. I added info that voting will be closed next Monday. Thank you, Milo Dne 15.12.2014 20:14, Andrea Faulds napsal(a): On 15 Dec 2014, at 18:08, Christoph Becker cmbecke...@gmx.de wrote: It seems to me that it's customary to specify the voting period *in advance* (cf. other RFC currently in the voting phase[1]). Not sure, though, if it's a problem to do otherwise. [1] https://wiki.php.net/rfc#in_voting_phase Yes, you should specify one ahead of time. Otherwise it looks like you are only closing it when convenient (e.g. extra yes vote at last minute). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] On the road to PHP 5.7 , or not ?
-Original Message- From: Adam Harvey [mailto:a...@adamharvey.name] Sent: Monday, December 15, 2014 8:06 PM To: Zeev Suraski Cc: PHP Internals Subject: Re: [PHP-DEV] On the road to PHP 5.7 , or not ? On 12 December 2014 at 23:19, Zeev Suraski z...@zend.com wrote: 3. Last (and probably least) - a 5.7 that breaks compatibility is inconsistent with our version strategy, that suggests 5.7 should be fully compatible with 5.6. Whoa — I'm not talking about breaking compatibility. I'm talking about generating deprecation warnings on things we know are going to break in PHP 7. Ok, that's borderline breaking compatibility if we want people to actually notice it (otherwise it'd be hidden by default settings). But I admit that's nitpicking, withdrawn :) Anyway, the #1 (literally) in my email was that the OP (Julien) clearly had a different 5.7 in mind than what you're describing. As I said, 5.7 wouldn't break anything, to my mind. The point is to provide a way for users to get a heads up on what things they need to be looking into to either migrate to PHP 7, or have a single code base that runs on both PHP 5 and 7, depending on their needs. The Python experience suggests that both of these cases _need_ to be supported, and well. Why wouldn't we — the people best placed to do so — provide the tooling to do that as part of the runtime? The strawman version of your position seems to be that users are going to just migrate to PHP 7 en masse, and that they'll be happy with their code breaking to tell them what to fix. I'm not sure there's any history in PHP or other languages that suggests that's really what will happen, and I think we're doing our users a disservice if we don't make the path to having a mixed 5/7 code base as easy as possible. I don't think people will migrate to PHP 7 en-masse. Our past experience with major versions (and even minor ones) doesn't support this thesis - it'll take time. But I do think that people who decide it's worth their while to migrate, will migrate and take the pain that it takes to make the necessary changes. The extra pain associated with migrating to an interim version - that does nothing but spew warnings in the right places -and obviously doesn't have any of the other features of 7 - doesn't seem to be a worthwhile experience for most users. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] On the road to PHP 5.7 , or not ?
-Original Message- From: a...@adamharvey.name [mailto:a...@adamharvey.name] On Behalf Of Adam Harvey Sent: Monday, December 15, 2014 8:12 PM To: Derick Rethans Cc: PHP Internals Subject: Re: [PHP-DEV] On the road to PHP 5.7 , or not ? On 15 December 2014 at 08:51, Derick Rethans der...@php.net wrote: Yes, I disagree. It's a time thing. Let's all work on one thing instead of *two*. Clearly you must see that there is not enough bandwidth? It will also prevent people from oh we can get this into 5.7 nonsense. It's not helpful, and it *is* fragmenting development. I'm just as cognisant of our time constraints as you are, but I still think this can work if there's a clear, written expectation (say via RFC) that 5.7 is for migration related changes only, and should not include new feature work. If we can keep this as 5.6 + some deprecation warnings, I believe that can reduce the QA/development load enough to make delivering it and 7.0 possible next year. 5.6 + deprecation warnings might be something we can even consider for the 5.6.x tree, as we get closer to release 7.0. I think if we do that, it becomes more interesting since the likelihood of people upgrading to such a version go higher (psychologically, moving to 5.7 is a much bigger deal than upgrading from 5.6.10 to 5.6.11). Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On the road to PHP 5.7 , or not ?
On Mon, Dec 15, 2014 at 8:45 PM, Zeev Suraski z...@zend.com wrote: -Original Message- From: a...@adamharvey.name [mailto:a...@adamharvey.name] On Behalf Of Adam Harvey Sent: Monday, December 15, 2014 8:12 PM To: Derick Rethans Cc: PHP Internals Subject: Re: [PHP-DEV] On the road to PHP 5.7 , or not ? On 15 December 2014 at 08:51, Derick Rethans der...@php.net wrote: Yes, I disagree. It's a time thing. Let's all work on one thing instead of *two*. Clearly you must see that there is not enough bandwidth? It will also prevent people from oh we can get this into 5.7 nonsense. It's not helpful, and it *is* fragmenting development. I'm just as cognisant of our time constraints as you are, but I still think this can work if there's a clear, written expectation (say via RFC) that 5.7 is for migration related changes only, and should not include new feature work. If we can keep this as 5.6 + some deprecation warnings, I believe that can reduce the QA/development load enough to make delivering it and 7.0 possible next year. 5.6 + deprecation warnings might be something we can even consider for the 5.6.x tree, as we get closer to release 7.0. I think if we do that, it becomes more interesting since the likelihood of people upgrading to such a version go higher (psychologically, moving to 5.7 is a much bigger deal than upgrading from 5.6.10 to 5.6.11). there are two advantages for having 5.7 and having those deprecated messages in 5.7: 1, if we introduce the deprecated message in 5.6.x, some people will miss it (for example debian jessie has 5.6.2) 2, would allow us to stabilize 5.6 instead of keep adding stuff to it continuously . -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
Hi! The fact that it *may* break *some* code that is used somewhere despite documentation recommending against it (pretty much deprecating it already for years) is a terrible reason not to re-evaluate the situation given the huge opportunity to correct this. It *will* break some code. There's no chance that somebody somewhere doesn't use this. And the change would break it. Worse yet, he won't be able to know about it until the customer complains about code logic being broken. The only thing that's bonkers here is outright refusal to make trivially breaking changes (in addition to numerous other breaking changes already accepted) simply for the sake of not breaking some 0.1% of outdated, There's not that many breaking changes accepted, and each of them had to be substantiated. We had other breaking changes is not a substantiation. For example, most uses of associativity are wrong ones - is, but that makes the idea of un-associating it even better, since unlike changing the associativity, it actually makes the problem obvious and easy to fix. Alternatively, of course, we could make a tool that detects this and alerts the user, but making it loud still sounds better. And the breakage we are discussing is not trivial - it's a logic change which makes code silently take different codepath without anybody knowing. In the world of BC breaks, this is one of the most evil ones. So we should avoid it as much as possible. Rather than simply pointing to a 3-year-old close-reason, it would be prudent to actually get statistics on how often this unexpected behavior is relied upon in large, popular codebases. Packagist Github, that Usually the burden of proof lays on whoever proposes the change. Note that a lot of code is not public, especially for languages like PHP that is used for websites - meaning, there's little reason to publicize any code but reusable library code. And the fact that the change would not break a handful of popular libraries doesn't mean it won't break scores of websites whose source you can not see, but which are way more important for the people using them than some library they don't use. Yes, I understand that this means very high burden on somebody proposing BC-breaking change, and it makes the development more conservative. It is a high burden convince people that this change is worth the risk of breaking potentially unknown code with unknown consequences. I think, however, it's better than actually suffering these consequences. Consider that however ugly this particular wart is, people has been living with it for almost 20 years, and it may be preferable for them to have somewhat ugly code than having broken code. It's short responses like this and the continued reliance on arguments posed in a different era/landscape that compel me to reconsider my continued participation in the PHP community at all. Sorry, but arguing from do this or that or I'm quitting does not seem a very strong argument to me. More drama does not help to evaluate the merits of changing the associativity of ?:. I think everybody here values the time of the volunteers that continue to contribute to the project, but I think keeping the discussion on the technical merits would be better. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] On the road to PHP 5.7 , or not ?
Am 15.12.2014 20:43 schrieb Zeev Suraski z...@zend.com: The extra pain associated with migrating to an interim version - that does nothing but spew warnings in the right places -and obviously doesn't have any of the other features of 7 - doesn't seem to be a worthwhile experience for most users. I dont't know about most users, I can only speak for myself from our small shop (in the big scheme of things...) production and development experience. I compile PHP myself for our setup, and have a nice compilation and deployment environment where I can easily throw new versions separately onto developer hosts and production hosts. We made our codebase E_STRICT|E_DEPRECATED-clean on the transition from 5.3 to 5.4, meanwhile migrated to 5.5, and soon to 5.6, with almost no pain, by first running new versions on developer machines and then on one of several production servers, where possibly issues are visible pretty fast. Now with PHP 7 promising potential for incompatibilities in a lot more areas, it would be, to us, a really useful option to have a 5.7 that is operationally fully compatible with 5.6 with added E_DEPRECATED for things bound to break. With that we could A) rub the developers' noses in the relevant deprecation messages for a while, _and_ run one or more rounds of one-of-the-production -server tests, gathering more deprecation messages there without fear of user visible effects. I cannot judge how much effort such a 5.7 would be for you as developers, and for the release managers, but I definitely would appreciate the effort, and I'm 100% sure that it would speed up our eventual adoption of PHP 7 by at least half a year, because the process would be much less risky. best regards Patrick
Re: [PHP-DEV] On the road to PHP 5.7 , or not ?
On 15/12/14 20:08, Ferenc Kovacs wrote: there are two advantages for having 5.7 and having those deprecated messages in 5.7: 1, if we introduce the deprecated message in 5.6.x, some people will miss it (for example debian jessie has 5.6.2) 2, would allow us to stabilize 5.6 instead of keep adding stuff to it continuously . And LTS versions can be ring fenced at 5.6 ... with just functional fixes. Perhaps what is needed is a tool which does identify the problems in 5.X code that need to be addressed in order to run clean in PHP7. Rather than encumbering PHP7 with E_STRICT type warning/error code, PHP5.7 would be a test environment to replace that functionality. Once code runs clean then one knows that it can be moved over? Style changes like the 'incorrect ternary '?' associativity' function would be highlighted so that BC problems are not silently changed. A properly documented migration tool rather than a production release as I would not expect to use PHP5.7 in a production environment! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
On Mon, Dec 15, 2014 at 12:11 PM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! The fact that it *may* break *some* code that is used somewhere despite documentation recommending against it (pretty much deprecating it already for years) is a terrible reason not to re-evaluate the situation given the huge opportunity to correct this. It *will* break some code. There's no chance that somebody somewhere doesn't use this. And the change would break it. Worse yet, he won't be able to know about it until the customer complains about code logic being broken. On what basis are you making that claim with such certitude? In all my years, I have yet to encounter a single, solitary case where someone's actually relying on PHP's wonky, counter-intuitive, non-standard associativity with the ternary operator. If such a one-in-a-billion scripts does exist somewhere, it's likely some PHP 4 thing that hasn't been touched in years. The only thing that's bonkers here is outright refusal to make trivially breaking changes (in addition to numerous other breaking changes already accepted) simply for the sake of not breaking some 0.1% of outdated, There's not that many breaking changes accepted, and each of them had to be substantiated. We had other breaking changes is not a substantiation. For example, most uses of associativity are wrong ones - is, but that makes the idea of un-associating it even better, since unlike changing the associativity, it actually makes the problem obvious and easy to fix. Alternatively, of course, we could make a tool that detects this and alerts the user, but making it loud still sounds better. And the breakage we are discussing is not trivial - it's a logic change which makes code silently take different codepath without anybody knowing. In the world of BC breaks, this is one of the most evil ones. So we should avoid it as much as possible. Rather than simply pointing to a 3-year-old close-reason, it would be prudent to actually get statistics on how often this unexpected behavior is relied upon in large, popular codebases. Packagist Github, that Usually the burden of proof lays on whoever proposes the change. Note that a lot of code is not public, especially for languages like PHP that is used for websites - meaning, there's little reason to publicize any code but reusable library code. And the fact that the change would not break a handful of popular libraries doesn't mean it won't break scores of websites whose source you can not see, but which are way more important for the people using them than some library they don't use. Yes, I understand that this means very high burden on somebody proposing BC-breaking change, and it makes the development more conservative. It is a high burden convince people that this change is worth the risk of breaking potentially unknown code with unknown consequences. I think, however, it's better than actually suffering these consequences. Consider that however ugly this particular wart is, people has been living with it for almost 20 years, and it may be preferable for them to have somewhat ugly code than having broken code. I don't think the we've been sick so long we're used to it now argument is very compelling. Some BC is expected in major revisions; and, historically, we have been WAY too conservative about that, in my view. When there's a major version and there's a BC-breaking change that either fixes something many people have been complaining about or improves the language in some other way without losing its identity, it should be a go. Major revisions are when changes like this are supposed to be made because, otherwise, these problems remain forever. I don't think it's rational to continue to ignore one of the most-requested fixes to PHP because one or two people out there may be relying on the broken behavior-- and yes, it is broken in the sense that it does not behave in the manner it's expected to for a C-like syntax. Didn't we talk about doing polls before? We should do a poll on this in the PHP community and see who, if anyone, has any code anywhere that relies on this confusingly counter-intuitive behavior. I would be amazed if even one person answered yes to that. So rather than continuing to guess and make unfounded assumptions, why don't we just ask them and settle the question here and now? --Kris It's short responses like this and the continued reliance on arguments posed in a different era/landscape that compel me to reconsider my continued participation in the PHP community at all. Sorry, but arguing from do this or that or I'm quitting does not seem a very strong argument to me. More drama does not help to evaluate the merits of changing the associativity of ?:. I think everybody here values the time of the volunteers that continue to contribute to the project, but I think keeping the discussion on the technical merits would be better. --
Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
On 12/15/2014 2:11 PM, Stanislav Malyshev wrote: There's not that many breaking changes accepted, and each of them had to be substantiated. We had other breaking changes is not a substantiation. For example, most uses of associativity are wrong ones - is, but that makes the idea of un-associating it even better, since unlike changing the associativity, it actually makes the problem obvious and easy to fix. Alternatively, of course, we could make a tool that detects this and alerts the user, but making it loud still sounds better. And the breakage we are discussing is not trivial - it's a logic change which makes code silently take different codepath without anybody knowing. In the world of BC breaks, this is one of the most evil ones. So we should avoid it as much as possible. The justification for not making breaking changes always grows as a function amount-of-code-in-the-wild which could possibly be relying on bugs. This situation results in a permanent conclusion of 'better-never' in lieu of 'better-now-than-later'. In PHP-land, the implication then is that this gridlock cannot be resolved even by major versions (IMO, one of very few reasons for major versions to exist *at all*). Usually the burden of proof lays on whoever proposes the change. Note that a lot of code is not public, especially for languages like PHP that is used for websites - meaning, there's little reason to publicize any code but reusable library code. And the fact that the change would not break a handful of popular libraries doesn't mean it won't break scores of websites whose source you can not see, but which are way more important for the people using them than some library they don't use. Yes, I understand that this means very high burden on somebody proposing BC-breaking change, and it makes the development more conservative. It is a high burden convince people that this change is worth the risk of breaking potentially unknown code with unknown consequences. Without telemetry, there is obviously no way of *ever* asserting that something is ripe for removal or even deprecation. So this burden of proof is unmeetable by definition. -- Leon Sorokin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On the road to PHP 5.7 , or not ?
On Mon, 2014-12-15 at 21:08 +0100, Ferenc Kovacs wrote: there are two advantages for having 5.7 and having those deprecated messages in 5.7: 1, if we introduce the deprecated message in 5.6.x, some people will miss it (for example debian jessie has 5.6.2) So you want Debian to upgrade to 5.7 instead of 7.0? - I'D rather see them on 7.0 as soon as possible. 2, would allow us to stabilize 5.6 instead of keep adding stuff to it continuously . New features in 5.6 should be rejected and added to 7.0 to give users more reasons to upgrade. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On the road to PHP 5.7 , or not ?
Hi, On 15 Dec 2014, at 23:32, Johannes Schlüter johan...@schlueters.de wrote: On Mon, 2014-12-15 at 21:08 +0100, Ferenc Kovacs wrote: there are two advantages for having 5.7 and having those deprecated messages in 5.7: 1, if we introduce the deprecated message in 5.6.x, some people will miss it (for example debian jessie has 5.6.2) So you want Debian to upgrade to 5.7 instead of 7.0? - I'D rather see them on 7.0 as soon as possible. Honestly, I don’t think Debian will switch to PHP 7, nor will any other distro, because it’s a new major version and it breaks things. `php` will probably continue to be PHP 5, they’ll add `php7`, prolong 5.6 or 5.7’s life for five years, and eventually switch `php` over to 7. 2, would allow us to stabilize 5.6 instead of keep adding stuff to it continuously . New features in 5.6 should be rejected and added to 7.0 to give users more reasons to upgrade. I agree on this one. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] PHP 5.7
Good evening, There has been some debate about whether to make “PHP 5.7. I have made a very simple RFC. It proposes a final minor version of PHP 5, PHP 5.7, to be released at the same time as PHP 7, with no new features whatsoever. The hope is that we can put this to a vote in 2 weeks’ time and settle the matter, just as we did with the PHP 6/7 name vote, although perhaps slightly less messily this time. ;) The RFC can be found here: https://wiki.php.net/rfc/php57 Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
Hi Adam, On 16 Dec 2014, at 00:15, Adam Harvey ahar...@php.net wrote: On 15 December 2014 at 16:09, Andrea Faulds a...@ajf.me wrote: The RFC can be found here: https://wiki.php.net/rfc/php57 Thanks for the taking the initiative on this. On timing: I think we should release 5.7 in August (12 months after 5.6), rather than lining it up with 7.0. This gives us the opportunity to then focus our attention on 7.0 entirely for the crucial RC phase of that release. Given the limited scope of 5.7, we shouldn't need as long a testing cycle. That’s a good point, it doesn’t actually have to line up with 7’s release and focus on 7.0 RC is crucial given the major changes. If others think this is a good idea, I’ll amend the RFC. Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] What ZEND_ACC_ALLOW_STATIC is supposed to do
Hi, I was looking at the documentation for DOMDocument::loadHTML() [1] that mentions the following: This function may also be called statically to load and create a DOMDocument object. The static invocation may be used when no DOMDocument properties need to be set prior to loading. However, this can’t be done in strict mode [2]: Strict Standards: Non-static method DOMDocument::loadHTML() should not be called statically in … This behaviour seems to be intended when ZEND_ACC_ALLOW_STATIC is used [3] and can be fixed by using ZEND_ACC_STATIC instead. My questions: 1) Is that the right kind of fix? 2) Is ZEND_ACC_ALLOW_STATIC meant to be used only for BC? If not, why are we raising strict errors? [1] http://php.net/manual/en/domdocument.loadhtml.php http://php.net/manual/en/domdocument.loadhtml.php [2] http://3v4l.org/JC7p0#v500 http://3v4l.org/JC7p0#v500 [3] http://lxr.php.net/xref/PHP_5_5/Zend/zend_vm_def.h#1935 http://lxr.php.net/xref/PHP_5_5/Zend/zend_vm_def.h#1935
Re: [PHP-DEV] What ZEND_ACC_ALLOW_STATIC is supposed to do
On 16 December 2014 00:56:43 GMT, Tjerk Meesters tjerk.meest...@gmail.com wrote: Hi, I was looking at the documentation for DOMDocument::loadHTML() [1] that mentions the following: This function may also be called statically to load and create a DOMDocument object. The static invocation may be used when no DOMDocument properties need to be set prior to loading. However, this can’t be done in strict mode [2]: Strict Standards: Non-static method DOMDocument::loadHTML() should not be called statically in … This behaviour seems to be intended when ZEND_ACC_ALLOW_STATIC is used [3] and can be fixed by using ZEND_ACC_STATIC instead. My questions: 1) Is that the right kind of fix? 2) Is ZEND_ACC_ALLOW_STATIC meant to be used only for BC? If not, why are we raising strict errors? Surely that's just the same as a userland method which happens not to use $this (allow static) and one marked static so *must* be called statically? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
On Mon, Dec 15, 2014 at 4:20 PM, Andrea Faulds a...@ajf.me wrote: Hi Adam, On 16 Dec 2014, at 00:15, Adam Harvey ahar...@php.net wrote: On 15 December 2014 at 16:09, Andrea Faulds a...@ajf.me wrote: The RFC can be found here: https://wiki.php.net/rfc/php57 Thanks for the taking the initiative on this. On timing: I think we should release 5.7 in August (12 months after 5.6), rather than lining it up with 7.0. This gives us the opportunity to then focus our attention on 7.0 entirely for the crucial RC phase of that release. Given the limited scope of 5.7, we shouldn't need as long a testing cycle. That’s a good point, it doesn’t actually have to line up with 7’s release and focus on 7.0 RC is crucial given the major changes. If others think this is a good idea, I’ll amend the RFC. Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php +1 on this. I agree with Adam; it'd be better to line up 5.7 with the support timeline for 5.6 and just handle 7's timeline separately. --Kris
Re: [PHP-DEV] [RFC] PHP 5.7
On Tue, Dec 16, 2014 at 8:09 AM, Andrea Faulds a...@ajf.me wrote: Good evening, There has been some debate about whether to make “PHP 5.7. I have made a very simple RFC. It proposes a final minor version of PHP 5, PHP 5.7, to be released at the same time as PHP 7, with no new features whatsoever. I am wondering why we need that? no new features I think we can extend 5.6 release cycle to avoid that.. thanks The hope is that we can put this to a vote in 2 weeks’ time and settle the matter, just as we did with the PHP 6/7 name vote, although perhaps slightly less messily this time. ;) The RFC can be found here: https://wiki.php.net/rfc/php57 Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
On 12/15/2014 11:59 AM, Robert Williams wrote:
What world is this that you live in where every line of code that’s written is
fully unit-tested
You took my example too literally; forget the unit tests. Imagine the
situation differently:
1. Someone wrote this function:
function add_five_pct($num) {
return $num * 1.10;
}
2. This function was then used to calculate profit margin and display
retail prices on your site and business has been great! Unknowingly,
you've been making 2x what was intended with no ill effects!
3. A new hire then went through this code on his own accord and decided,
'wait, this function is a bug!' and took it upon himself to fix it to
'$num * 1.05'.
Would you say the e-commerce site has been 'fixed' to work correctly?
Should the dev be praised for fixing the clearly broken function without
consulting anyone?
I cannot come up with a clearer explanation of how a 'silent' code fix
can foul up the bigger picture in non-beneficial ways. That's the
scenario that's being discussed here. The main point of contention is,
no one knows how much code exists in the wild that uses and relies on
this misbehavior. My argument is 'negligible', others say it's
'non-negligible'. And the whole comedy is, no one can actually provide
definitive numbers since nobody will ever know but a tiny portion of all
source code that is out there, so all arguments stem from 'meta'
evidence and personal experience.
--
Leon Sorokin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
On Mon, Dec 15, 2014 at 8:19 PM, Leon Sorokin leeon...@gmail.com wrote:
On 12/15/2014 11:59 AM, Robert Williams wrote:
What world is this that you live in where every line of code that’s
written is fully unit-tested
You took my example too literally; forget the unit tests. Imagine the
situation differently:
1. Someone wrote this function:
function add_five_pct($num) {
return $num * 1.10;
}
2. This function was then used to calculate profit margin and display
retail prices on your site and business has been great! Unknowingly, you've
been making 2x what was intended with no ill effects!
3. A new hire then went through this code on his own accord and decided,
'wait, this function is a bug!' and took it upon himself to fix it to '$num
* 1.05'.
Would you say the e-commerce site has been 'fixed' to work correctly?
Should the dev be praised for fixing the clearly broken function without
consulting anyone?
I cannot come up with a clearer explanation of how a 'silent' code fix can
foul up the bigger picture in non-beneficial ways. That's the scenario
that's being discussed here. The main point of contention is, no one knows
how much code exists in the wild that uses and relies on this misbehavior.
My argument is 'negligible', others say it's 'non-negligible'. And the
whole comedy is, no one can actually provide definitive numbers since
nobody will ever know but a tiny portion of all source code that is out
there, so all arguments stem from 'meta' evidence and personal experience.
--
Leon Sorokin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Precisely why I suggested we do a poll and find out. Polling is a valid
means of getting a reasonable accounting of a particular metric. If we use
a sufficiently diverse and representative sample, we should easily be able
to get accurate enough results to settle this question once and for all.
The only cost is effort.
--Kris
Re: [PHP-DEV] [RFC] PHP 5.7
Hi Xinchen, On 16 Dec 2014, at 04:07, Xinchen Hui larue...@php.net wrote: On Tue, Dec 16, 2014 at 8:09 AM, Andrea Faulds a...@ajf.me wrote: Good evening, There has been some debate about whether to make “PHP 5.7. I have made a very simple RFC. It proposes a final minor version of PHP 5, PHP 5.7, to be released at the same time as PHP 7, with no new features whatsoever. I am wondering why we need that? no new features…. The reasoning behind this is to encourage people to switch to PHP 7 if they want new features. I think we can extend 5.6 release cycle to avoid that.. We could, but we wouldn’t be able to introduce deprecation notices in a 5.6 micro, so we’d need a new minor releases. Also, I failed to mention it in the RFC (will do so), but for any new reserved words in PHP 7, we should also reserve them in 5.7. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] IntlChar class and intl_char_*() functions
On Mon, Nov 24, 2014 at 8:47 PM, Sara Golemon poll...@php.net wrote: While playing around with Andrea's unicode literals syntax proposal, I was reminded of just how little of ICU is exposed. I've put up a short proposal for adding IntlChar exporting these APIs as static methods (with a matching non-oop interface). https://wiki.php.net/rfc/intl.char Full implementation available now at https://github.com/sgolemon/php-src/compare/intl.uchar RFC updated to remove the functional API and clarify some things based on what I learned while implementing. Pay special attention to the #notes section regarding $limit which I think is a somewhat non-PHP API. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
There has been some debate about whether to make “PHP 5.7. I have made a very simple RFC. It proposes a final minor version of PHP 5, PHP 5.7, to be released at the same time as PHP 7, with no new features whatsoever. I am wondering why we need that? no new features I think we can extend 5.6 release cycle to avoid that.. Extending the PHP 5.6 release cycle doesn't give an opportunity to raise different E_STRICT and E_DEPRECATED messages in preparation for PHP 7.0. This may or may not be something you value, but it's something I personally value. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
Hi everyone, On 16 Dec 2014, at 00:15, Adam Harvey ahar...@php.net wrote: On 15 December 2014 at 16:09, Andrea Faulds a...@ajf.me wrote: The RFC can be found here: https://wiki.php.net/rfc/php57 Thanks for the taking the initiative on this. On timing: I think we should release 5.7 in August (12 months after 5.6), rather than lining it up with 7.0. This gives us the opportunity to then focus our attention on 7.0 entirely for the crucial RC phase of that release. Given the limited scope of 5.7, we shouldn't need as long a testing cycle. On 16 Dec 2014, at 01:19, Kris Craig kris.cr...@gmail.com wrote: +1 on this. I agree with Adam; it'd be better to line up 5.7 with the support timeline for 5.6 and just handle 7's timeline separately. I’ve updated the RFC to target August 2015 for release. This would mean it would come out a year after 5.6, and the RC phase would be half as PHP 7’s. On 16 Dec 2014, at 05:51, Andrea Faulds a...@ajf.me wrote: Also, I failed to mention it in the RFC (will do so), but for any new reserved words in PHP 7, we should also reserve them in 5.7. I’ve also updated the to note that reserved words in PHP 7 can be pre-reserved in PHP 5.7. Thanks for your comments! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Consistent type names in error messages
Am 14.12.2014 um 19:35 schrieb Andrea Faulds: Thoughts? +1 for consistency :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
On 16/12/2014 05:07, Xinchen Hui wrote: On Tue, Dec 16, 2014 at 8:09 AM, Andrea Faulds a...@ajf.me wrote: Good evening, There has been some debate about whether to make “PHP 5.7. I have made a very simple RFC. It proposes a final minor version of PHP 5, PHP 5.7, to be released at the same time as PHP 7, with no new features whatsoever. I am wondering why we need that? no new features I think we can extend 5.6 release cycle to avoid that.. I tend to agree with Xinchen here. A new minor release just to introduce a few deprecation messages? It sounds like a lot of work (it also need to be maintained) for little gain. I think that doesn't also match the plans of other (accepted?) RFCs that were targeted for 5.7. I think I've seen it many times. Cheers -- Matteo Beccati Development Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
Hi Matteo, On 16 Dec 2014, at 07:52, Matteo Beccati p...@beccati.com wrote: On 16/12/2014 05:07, Xinchen Hui wrote: On Tue, Dec 16, 2014 at 8:09 AM, Andrea Faulds a...@ajf.me wrote: Good evening, There has been some debate about whether to make “PHP 5.7. I have made a very simple RFC. It proposes a final minor version of PHP 5, PHP 5.7, to be released at the same time as PHP 7, with no new features whatsoever. I am wondering why we need that? no new features I think we can extend 5.6 release cycle to avoid that.. I tend to agree with Xinchen here. A new minor release just to introduce a few deprecation messages? It sounds like a lot of work (it also need to be maintained) for little gain. There should be very little work necessary. Deprecations are easy, and the changeset from 5.6 should be tiny at best. The only significant extra work is the added year of maintenance for the PHP 5 line. I think that doesn't also match the plans of other (accepted?) RFCs that were targeted for 5.7. I think I've seen it many times. Could you tell me which RFCs targeted 5.7 and didn’t just add deprecation notices? I’m unaware of any. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] PHP 5.7
On Tue, Dec 16, 2014 at 8:52 AM, Matteo Beccati p...@beccati.com wrote: On 16/12/2014 05:07, Xinchen Hui wrote: On Tue, Dec 16, 2014 at 8:09 AM, Andrea Faulds a...@ajf.me wrote: Good evening, There has been some debate about whether to make “PHP 5.7. I have made a very simple RFC. It proposes a final minor version of PHP 5, PHP 5.7, to be released at the same time as PHP 7, with no new features whatsoever. I am wondering why we need that? no new features I think we can extend 5.6 release cycle to avoid that.. I tend to agree with Xinchen here. A new minor release just to introduce a few deprecation messages? It sounds like a lot of work (it also need to be maintained) for little gain. I think that doesn't also match the plans of other (accepted?) RFCs that were targeted for 5.7. I think I've seen it many times. We already has one accepted RFC which targets 5.7, and as I mentioned before 5.7.0 wouldn't be featureless, but would contain the small self-contained features which are currently targeting 5.6.x. So 5.7.0 would be a minor version without new major features, but also no BC break, would allow us to make 5.6 more stable, and be a stepping stone for 7.0 with the deprecated errors. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
