Hello, On Wed, 7 Aug 2019 at 19:03, Chase Peeler <chasepee...@gmail.com> wrote: > > > > On Wed, Aug 7, 2019 at 1:00 PM Peter Kokot <peterko...@gmail.com> wrote: >> >> Hello. >> >> On Wed, 7 Aug 2019 at 18:56, Chase Peeler <chasepee...@gmail.com> wrote: >> > >> > >> > >> > On Wed, Aug 7, 2019 at 12:45 PM Peter Kokot <peterko...@gmail.com> wrote: >> >> >> >> On Wed, 7 Aug 2019 at 16:14, Zeev Suraski <z...@php.net> wrote: >> >> > >> >> > >> >> > >> >> > On Wed, Aug 7, 2019 at 4:56 PM Dan Ackroyd <dan...@basereality.com> >> >> > wrote: >> >> >> >> >> >> On Wed, 7 Aug 2019 at 09:45, Peter Kokot <peterko...@gmail.com> wrote: >> >> >> > >> >> >> > Yes, last time I was asking this, there was a clarification that >> >> >> > certain people from the group internals can veto particular RFC. >> >> >> >> >> >> Please could you point to where this alleged rule has ever been >> >> >> written down or agreed to? >> >> > >> >> > >> >> > There's indeed no such rule that any individuals have a veto power. >> >> > >> >> >> >> >> >> Although certain people may have claimed this is a rule, it's never >> >> >> been agreed afaik. >> >> > >> >> > >> >> > I'm not aware of anybody who ever claimed that such a rule existed, >> >> > either. If people are alluding to me - then I don't claim I can veto >> >> > anything; I think it's also clear from what I think about the short >> >> > tags deprecation RFC that if I had veto power, that would be an >> >> > instance where I'd use it. The reason we went for V2 aren't because of >> >> > a veto, but because of issues in the previous RFC. >> >> > >> >> > With that said - the source code of PHP is copyrighted by the PHP Group >> >> > - and it's a fact that is mentioned at the top of every PHP source >> >> > file. The PHP Group is mostly inactive, and will likely stay this way, >> >> > but under some extreme situations - it might choose to act (if ever - >> >> > probably primarily around things that have to do with process). >> >> > >> >> >> I think when we adopt a Code of Conduct one of the things we need to >> >> >> make explicit is that "claiming authority that is not codified" is >> >> >> explicitly a thing that will not be allowed in internals discussions >> >> >> as it seems to keep happening and results in a lot of confusion, and >> >> >> frustration. >> >> > >> >> > >> >> > The more accurate word here is 'if', rather than 'when'. But I don't >> >> > think there's a need to wait for a CoC on this one - it should be clear >> >> > that no individual has veto powers, but it should be also clear that >> >> > not everything is up for a vote. >> >> > >> >> > Zeev >> >> > >> >> >> >> Veto has been mentioned here >> >> https://externals.io/message/105201#105558 >> >> >> >> I'm not having any issues with veto being used here or not on a >> >> previous RFC from people that are in the internals since day 1. I >> >> think we should respect that they have issues with proposals coming up >> >> in recent years, but hopefully group will also understand us - users >> >> and new contributors a bit that we just want to have a bit of cleanup >> >> of legacy things here and there :) >> >> >> >> Thanks and have a nice day. >> >> -- >> >> Peter Kokot >> >> >> >> -- >> >> PHP Internals - PHP Runtime Development Mailing List >> >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> >> > What powers are available, and to whom they are available, is probably >> > something that should be moved to another thread. We currently have at >> > least three different discussions going on in this thread: >> > 1.) The RFC itself >> > 2.) Default handling of the ini setting >> > 3.) Whether certain people can veto RFCs. >> > >> > To address Andrey's initial concern, which is currently leading to him not >> > voting: >> > >> > Nobody is vetoing anything. Due to both the procedural issues (the way the >> > voting was structured with two options) as well as the severity of the >> > issues raised after the voting, another RFC was proposed that supersedes >> > the original RFC. The procedural issues alone were enough to warrant >> > another vote on an RFC that had fixed those issues. This means that, for >> > all intents and purposes, the first RFC never existed. If the current RFC >> > passes, then it will be implemented as proposed. If it fails, then >> > treatment of short tags will remain as it currently is. >> > >> > I hope you will reconsider your decision to not vote on this new RFC. I >> > understand your concerns. As someone that didn't like the outcome of the >> > first vote either, I also didn't feel that a revote just because a lot of >> > people decided to speak up after the fact was the correct course of >> > action. I don't think that is what is happening here, though. >> > >> > -- >> > Chase Peeler >> > chasepee...@gmail.com >> >> Just to be more clear here. If the RFC fails then the short opening >> tags will stay in PHP for ever. I'm not sure what will change in 5 or >> 10 years so much so considering the feedback I think we should then >> leave them in for ever and enable them by default everywhere and have >> two PHP opening tags. Yes, this is what happens when there is no plan >> from key people involved here. >> > And why is supporting two types of opening tags so bad that it justifies such > a large BC break? Support for short tags has existed since PHP3. Can you > point to anything you've written or used that would have been better had > short tags never existed? > >> >> -- >> Peter Kokot > > > > -- > Chase Peeler > chasepee...@gmail.com
Considering that you're in favor of keeping the short opening tag in PHP "forever" because you haven't added any kind of other solution either by now neither you see an issue with this... I think the worst situation for language is that there is an option to write non portable code with this unfortunate short tag. It won't work everywhere. So, this is already a reason for thinking forward (at least from the progress and consistency point of view): A - removing one of the two options, so it is simpler to write portable code without warning users? or B - making both options always available so code is portable everywhere. The A is a compromise to ditch that legacy code and upgrade it (in a major version like PHP 9 - this is 5+ years from now). Option B is a way into a stable solution and also gazillion other problems that arise with it. From nicely explained ones in the RFC, to the teaching two things, etc. With option B there will soon happen also something else. Why using a longer tag if code can be a bit "shorter" and simpler with a short opening tag then? You can imagine the impossibility of removing the long tag from PHP just like that in some decent time, where we will have realistic option to push it to production... (option C): Postponing things to PHP 10 is simple and easy way out here but I'm not sure what is the point in that. We will have the same discussion then. It is way too far away from my understanding. Something like this in short. -- Peter Kokot -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
