Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106420 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 56008 invoked from network); 7 Aug 2019 20:18:03 -0000 Received: from unknown (HELO mail-ot1-f54.google.com) (209.85.210.54) by pb1.pair.com with SMTP; 7 Aug 2019 20:18:03 -0000 Received: by mail-ot1-f54.google.com with SMTP id o101so107646339ota.8 for ; Wed, 07 Aug 2019 10:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=J8Fm7kStU7kPNgxJ2A6A4g/ktmYtFt+dOiebKeiM93s=; b=CHQ2+vYLFowGDTT3/OWfYdrqjGK7ioNb4WoP9DjMl7AtWK685kgJpykZH7/iUD2fCm nFsVAzpXTI6b9OoVJQcxuD3CxlLhTqDSToI8bH3vPoBN4PV5xNzEf7BHEa3m9cU7eq+1 9PPRCZuf7Vp9z6LvwVL1bSiTXrchL4zf9h9xNq7s64UIRTNLby0cIUeE73Qpryg6kQc5 o6FgIg4YwMeAfRkejefxE0nYUvPlIaVAR1MrBY36vgBXNLsw+Od/e1JOsHnxMYeOva0T vti3agJRe2YnlQxrSvIrFpSYUg2ZjvRvEfvrUDTeN7xgOtvTGtB9Nl7523iGgv7J+XtF pBdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=J8Fm7kStU7kPNgxJ2A6A4g/ktmYtFt+dOiebKeiM93s=; b=q/pQ/5H7URqDU5y3UdPmd3hGBm0Pw6V++3Zn8PrjmdiPldm+UgGqgElejAzkgx5gOM L6H2L7X7Q2voEuIds85Pigujom2bnvqK8OPBqcl4MMn/V8h0a1b6WHwW5wTlWd2+a6pg pbDjGslJPw0zQTyjcBVR8dDk+cgWrCmmuF+WU4RMvuTcoB3Uph/j5QaMKCn+lPCThgOD py8f/sBjVbRbZDMDnlb1/zD7H3fFOHLG43waAHNDhnY0EaazcSWsNuZemfi3OypWnhT6 Ge3yvo1RkiaCWucSEOMqEMJtVJSxU9JOHYMHUVmYWE5o6s6lrDOdE4fUCugdak0rmztu w8IA== X-Gm-Message-State: APjAAAUACqByht4W9MLwm83NY0czSBneozPXxNqWlImb5a/tGI1AwYDQ KVUxvxpZ9dTIH+p9JlJdjkgMm8B0burl8H977Vw= X-Google-Smtp-Source: APXvYqzOfE8ZwCqq490eGn4eHsnFI9h95LnFfEkJwJ1dI8xEuMMXtnwV9t5bGs2LkcDAHktIw1JeXaSve7ZIs/aD56E= X-Received: by 2002:a9d:a76:: with SMTP id 109mr8181146otg.252.1565199899490; Wed, 07 Aug 2019 10:44:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 7 Aug 2019 19:44:47 +0200 Message-ID: To: Chase Peeler Cc: Zeev Suraski , Dan Ackroyd , Andrey Andreev , "G. P. B." , PHP internals Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again From: peterkokot@gmail.com (Peter Kokot) Hello, On Wed, 7 Aug 2019 at 19:03, Chase Peeler wrote: > > > > On Wed, Aug 7, 2019 at 1:00 PM Peter Kokot wrote: >> >> Hello. >> >> On Wed, 7 Aug 2019 at 18:56, Chase Peeler wrote: >> > >> > >> > >> > On Wed, Aug 7, 2019 at 12:45 PM Peter Kokot wro= te: >> >> >> >> On Wed, 7 Aug 2019 at 16:14, Zeev Suraski wrote: >> >> > >> >> > >> >> > >> >> > On Wed, Aug 7, 2019 at 4:56 PM Dan Ackroyd = wrote: >> >> >> >> >> >> On Wed, 7 Aug 2019 at 09:45, Peter Kokot wr= ote: >> >> >> > >> >> >> > 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 neve= r >> >> >> 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 anyt= hing; I think it's also clear from what I think about the short tags depre= cation RFC that if I had veto power, that would be an instance where I'd us= e it. The reason we went for V2 aren't because of a veto, but because of i= ssues in the previous RFC. >> >> > >> >> > With that said - the source code of PHP is copyrighted by the PHP G= roup - and it's a fact that is mentioned at the top of every PHP source fil= e. The PHP Group is mostly inactive, and will likely stay this way, but un= der some extreme situations - it might choose to act (if ever - probably pr= imarily 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 discussio= ns >> >> >> as it seems to keep happening and results in a lot of confusion, a= nd >> >> >> 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 t= hat no individual has veto powers, but it should be also clear that not eve= rything 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 u= p >> >> 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 lea= st 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 t= he 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 inten= ts and purposes, the first RFC never existed. If the current RFC passes, th= en 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 p= eople 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 >> > chasepeeler@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 y= ou point to anything you've written or used that would have been better had= short tags never existed? > >> >> -- >> Peter Kokot > > > > -- > Chase Peeler > chasepeeler@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. --=20 Peter Kokot