Re: [RFC] [DISCUSSION] Deprecate PHP's short open tags V2

On Wed, Jul 24, 2019 at 9:27 AM G. P. B. <george.banyard@gmail.com> wrote: > On Tue, 23 Jul 2019 at 22:22, Stanislav Malyshev <smalyshev@gmail.com> > wrote: > > > Hi! > > > > > Due to the controversy after the initial vote on the Deprecate PHP's > > Short > > > Open Tag RFC [1] here is a new RFC to deprecate them written with the > > help > > > of Nikita Popov <nikic@php.net>. > > > > Could you please explain what has changed since the last time we > > discussed it that makes it necessary to bring the second RFC on the same > > topic? > > > > On Wed, 24 Jul 2019 at 02:41, Stanislav Malyshev <smalyshev@gmail.com> > wrote: > > > Hi! > > > > > V2 remedies that by maintaining default INI behaviour, as well as > > > nullifying the possibility of code / data leaks by throwing a compiler > > > exception if <? is encountered (and enabled), thus denying the VM an > > > opportunity to execute a file which contains potentially leaky code. > > > > Oh, I thought it was already agreed upon... I thought the RFC somehow > > modifies upon that. I think parse error for 8.x would be acceptable. > > > > -- > > Stas Malyshev > > smalyshev@gmail.com > > > > Nothing, this is a courtesy vote as the implementation proposed in this RFC > is the one which would be used to implement the previous RFC even though > it is not the one proposed initially. > > Now if we can all agree that this can land without needing to go through > this > whole process I think everybody wins: we all don't need to spend time on > this, > it can be merged as it, the RMs could re-tag Beta 1 (which may will need to > happen because of some problems with the wincache extension from what > I'm seeing) which puts less strain on them IMHO. > Because I'm pretty sure I'm one of the most annoyed to need to go through > this process once again. > Is this going to happen? Probably not so here we are. > > On Wed, 24 Jul 2019 at 05:51, <vsuraski@gmail.com> wrote: > > > - [Short tags] You need to purposely turn it on in your own deployment - > > people and companies who use it use it exclusively for internal purposes. > > > > This is just plain wrong since PHP 5.4 as it is enabled by default and you > need to actively turn it OFF as which can be seen on > https://3v4l.org [1] > as it doesn't use any INI configuration files. Now as stated in the RFC: > > > Currently the <? short open tag is controlled by the short_open_tag > > ini setting. This ini setting is *enabled* by default (if no ini files is > > used), > > but *disabled* in both php.ini-development and php.ini-production. > > > which is probably why most of us - and most users - think that it needs to > be implicitly enabled. > > > I've modified the RFC to state the removal of the short_open-tags in PHP > 9.0. > > Best regards > > George P. Banyard > > [1] https://3v4l.org/kKDI9 > I was very vocal in regards to the first RFC (both before and after the vote) so I figured I'd should say something about this RFC. My overall opinion remains the same: There is still no justification for removing short tags that justifies the BC break. I pretty much agree with everything Zeev said in his email. That being said, I think this RFC handles the deprecation process much better. My objections to the previous RFC were two-fold: 1.) benefits didn't outweigh harms and 2.) deprecation/removal path was dangerous and harmful. I still think #1 applies to this RFC. I do not think #2 does. While I agree with some others that the it might be better to postpone the decision about the ultimate removal to a later date, I don't think slating it for 9.0 is that big of a deal. I think it also gives people much more time to adapt than previous road maps. -- Chase Peeler chasepeeler@gmail.com