On Tue, 20 Aug 2019 at 18:02, Chase Peeler <chasepee...@gmail.com> wrote: > > On Tue, Aug 20, 2019 at 11:50 AM Peter Kokot <peterko...@gmail.com> wrote: > > > On Tue, 20 Aug 2019 at 14:51, G. P. B. <george.bany...@gmail.com> wrote: > > > > > > Hello internals, > > > > > > This RFC has been declined with 56% in favour (30/54) and 44% against > > > (24/54). > > > > > > Two side notes to this: > > > > > > - I seriously don't appreciate that the RFC has been edited *WITHOUT* > > my > > > knowledge to add endorsement names on the counterargument to the RFC on > > the > > > RFC itself when the appropriate place would have been the counter > > argument > > > document. > > > - As it has no clear supra majority (nor against nor in favour), this > > > topic should probably be put to discussion again in some way or form at a > > > later stage. > > > > > > Best regards > > > > > > George P. Banyard > > > > The number of things that got wrong in these two RFCs is > > extraordinary. > > What was done incorrectly in regards to the second RFC? > > > > If anything the community, the internals and everyone > > involved got through a good thinking process so we have learned > > something from this in any way. I appreciate all your time and effort > > to move this thing forward and even for being so respectful towards > > Zeev, Rasmus, Dmitry, and Sara who have endorsed keeping them in the > > PHP and to repeat the voting with a better solution in this RFC. > > > > You say that like being respectful to people with opinion different than > yours is something worth commending, when it should be the default > behavior. In other words, you are implying that anyone that opposed this > RFC didn't deserve respect, so, congratulations to everyone for showing it > anyway. > > > > I think that now we need to fix the documentations out there. short > > tags will stay in PHP for at least another 10+ years, so maybe we > > should simply consider them not a part of legacy but a special kind of > > a feature. There are some parts in PHP comments and docs that needs > > this fixed and sorted out better a bit (probably - specially in the > > ini files itself etc). > > > > I think we should still discourage their use. We should be explicit in the > documentation that code which uses short tags might not be portable. Just > because they exist, doesn't mean we should suddenly change our treatment of > them when it comes to best practices. If there is any documentation that > doesn't make this clear, submit a bug report. > > If you really feel that we should start treating short tags as totally > legitimate, then someone else with better knowledge of how to proceed with > that will need to provide advice. >
Let's simplify this a bit because I'm not sure I have seen anyone mentioning something like a PHP 10 milestone in all these discussions. If we want to get rid of some feature like this a very long timeline needs to be done and also major versions needs to be taken into consideration. And from all the discussions I got a feeling that not everyone who voted "No" (who want the short tags in PHP) also want to get rid of them. Ever. So that's why. We can live with short tags in PHP as a feature. And so can legacy projects be upgraded to not use them anymore so nothing to worry too much I think anymore now. We'll discuss this maybe in 5 or 10 years then. About the docs - there are very minor changes needed where "backwards compatibility" is mentioned maybe. Because they are not in PHP for keeping BC anymore now. Nobody proposed a better solution than this RFC, then they are a feature. Cheers. -- Peter Kokot -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
