Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104928
MIME-Version: 1.0
References: <CAFPFaML1KT2WMhUkZg4rZz3BDV68oPCCufx5+0c26Js--gXj_Q@mail.gmail.com>
 <000301d4e312$06a88190$13f984b0$@roze.lv>
In-Reply-To: <000301d4e312$06a88190$13f984b0$@roze.lv>
Date: Mon, 25 Mar 2019 10:05:42 -0400
Message-ID: <CAPKYkKzuVriP-qNWM9TzRLNeaLd-oO1WXxxWXmWoujgyGtGarw@mail.gmail.com>
To: Reinis Rozitis <r@roze.lv>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ecd3730584ebb337"
Subject: Re: [PHP-DEV] [RFC] Deprecate PHP's short open tags
From: chasepeeler@gmail.com (Chase Peeler)

--000000000000ecd3730584ebb337
Content-Type: text/plain; charset="UTF-8"

On Mon, Mar 25, 2019 at 9:52 AM Reinis Rozitis <r@roze.lv> wrote:

> > I would like to start the discussion about the deprecation of PHP's
> short open
> > tags:
> > https://wiki.php.net/rfc/deprecate_php_short_tags
>
> 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'.
>
> I'm still unclear on the advantages as well


> 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.
>
> Our application (an internal webapp) has a large amount of legacy code
that we try to avoid messing with because we are actively rebuilding
everything. Everytime there is a BC break we have to go back into that
legacy code. So, while any active development of our application uses
"recent application code" that is that difficult to maintain, we still have
a lot of spaghetti code that we rarely have to deal with except when it
comes time to upgrade PHP. This often leads to the upgrades getting pushed
out further and further.

I'm not against BC breaks. They are a necessary evil to make PHP a better
language. However, I think there should be a clear reason why the
advantages outweigh the disadvantages. I'm not seeing that in this case.


> [1] https://w3techs.com/technologies/details/pl-php/all/all
>
> rr
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 
Chase Peeler
chasepeeler@gmail.com

--000000000000ecd3730584ebb337--