Seems like the discussion is split between this thread and the previous one. This is maybe due to me not linking the RFC announcement email in the RFC immediately and I apologize for this inconvenience. I will try to answer to most things within the announcement thread. If I missed someone could they please notify me.
On Mon, 25 Mar 2019 at 14:52, Reinis Rozitis <r...@roze.lv> wrote: > Hi, > I did read the initial thread about this and now the RFC and it doesn't > really state what is the reason of removing the short tags besides this one > line: > "PHP has provided over the years different ways to indicate the beginning > of PHP code other than the standard <?php ... ?>" > > Is there a (noticeable) speed improvement or does it make the > parser/engine more simple? Is it wrong to provide different ways to > indicate the start of php code? > Since the short '<?' came first one could argue which is the 'standard'. > You could argue that '<?' is the standard as it came first however, the documentation discourages it and all examples in the PHP documentation use the long open ta '<?php' which IMHO says that this is the standard way on how to indicate the beginning of PHP code. It does simplify the parser slightly as it doesn't need to check everytime it encounters a '<?' if it should start parsing code or not. But to say this is a speed improvement no idea as I haven't done any benchmarks. > Also considering there is somewhat low adoption of new php versions [1] a > change which brakes a lot of legacy code might even further push back the > switch to modern/current versions (at least now even if the defaults > disable the short tags, there is an option to reenable the functionality). > Obviously you could say that those using old versions won't be affected > anyways and those using php 7.x and waiting for 8.x will use recent > application code and also won't notice this deprecation, but in my opinion > (and praxes) it isn't always the case. > > [1] https://w3techs.com/technologies/details/pl-php/all/all > > rr > Just as a reminder exposing PHP's version can be disabled with the "expose_php" INI setting. Maybe this is just me idealising stuff but as there is automatics tooling (as pointed out by Côme Chilliet) I would suppose that upgrading from PHP 7 to PHP 8 wouldn't be harder if PHP's short open tags get removed. On Mon, 25 Mar 2019 at 16:38, Andrey Andreev <n...@devilix.net> wrote: > OK, so why not flip it and make it always available instead? I'm aware > of the potential XML conflict, but I've personally never seen it, so > to me that looks like the lesser evil compared to a massive BC break. > > Cheers, > Andrey. Technically this is already the case, the default in the engine is to enable PHP's short open tags, however both INI config templates provided with PHP (php.ini-developement and php.ini-production) disable PHP's short open tags. So if PHP's short open tags are to be considered "full class" open tags this should be represented in the INI templates. But I won't be the one pushing for this change. On Mon, 25 Mar 2019 at 16:16, Johannes Schlüter <johan...@schlueters.de> wrote: > On Mo, 2019-03-25 at 09:38 -0500, Sara Golemon wrote: > > > > As we stand now, code using short open tags works when those tags are > > enabled. As we'd stand in the future, that code would not work. > > That > > level of BC break requires a strong justification. > > The code would not simply "not work" but even potentially leak to the > client (as PHP would not treat it as code) which could leak credentials > or other sensitive information. > I think this can be an interesting point to add to the RFC as why to deprecate the short open tags. I still think that long-term goal should be that language behavior > doesn't depend on ini configuration. > > [...] > > johannes > This is mostly my reasonning on why bringing this RFC to the table. On Mon, 25 Mar 2019 at 17:21, Rasmus Schultz <ras...@mindplay.dk> wrote: > For the record, we're a mid-size organization, building a modern product on > PHP 7 with a PSR-based stack. > > We've shunned template engines and rely heavily on short open tags and > alternative control-structures - mainly because we insist on static > analysis and IDE support, which we get by manually type-hinting a single > view-model variable $view at the beginning of each template. > > No other template engine gives us what we want in terms of static analysis, > type-checking or IDE support. > > The choice to rebuild a very large product in PHP vs e.g. Node, at the > time, was in part motivated by PHP's template features - which, while it > may look pretty verbose and ugly on the surface, has a huge advantage over > basically anything else, e.g. static analysis with various QA tools, > automated refactorings (rename etc.) in PHP Storm, and so on. > > The loss of this feature would be a substantial setback for our > organization - for which there is no really good replacement. This is an interesting use case, however may I ask why using '<?' instead of '<?php' except to make something verbose a tad less verbose? Also would PHP_CS_FIXER be able to convert all short open tags into full openings tags to ease transition (I suppose it would but you can never be too sure)? Finally I'm also open to a change in timeline such as changing the Engine default from On to Off in PHP 7.4 and only deprecate the INI setting in PHP 8 with the removal of it pushed back to a later version. This is not my prefered way of doing it but I can live with this way of going forward. Best regards George P. Banyard
