Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106440
MIME-Version: 1.0
References: <CAFPFaML19B_RehrUQLEy_oFae-H5r3+BpUGg=GF1js83cJpJqQ@mail.gmail.com>
 <CAOWwgpn=9HZ8j2xMn-ENwZ5caAO4VRFJ5MLk0f=GLhjzHO7Czw@mail.gmail.com>
 <CAPKYkKw2b1pgRHMJSF3Kk+w55hch6yu3WdyEC0yAe0Z7Hh=8tA@mail.gmail.com>
 <1759114.DMe9nKvMbn@mcmic-probook> <62c73b8f-df41-43c2-bb51-ceeaf607cacf@Spark>
 <CAJHtzny-v=AEh3U3t=xTakmjzwnkLS1FAwWsZ2+7_iWrmaHVJw@mail.gmail.com>
 <CAPKYkKx5GBdYRofiRvfYCqSO80wxdAqN1mC6keU3LWWLPT-UJg@mail.gmail.com> <CAAfnsFXoibPNAK3JyTZmp21-6HibW4TQoPFxWG6miiE_tFpApQ@mail.gmail.com>
In-Reply-To: <CAAfnsFXoibPNAK3JyTZmp21-6HibW4TQoPFxWG6miiE_tFpApQ@mail.gmail.com>
Date: Thu, 8 Aug 2019 17:17:32 +0200
Message-ID: <CAL0xaBFUiNAPCnz=rAi8w95SqWP0ZrMZQOkSt3TQaf6=dg+tVQ@mail.gmail.com>
To: Peter Kokot <peterkokot@gmail.com>
Cc: Chase Peeler <chasepeeler@gmail.com>, Zeev Suraski <zeev@php.net>, Brent <brendt@stitcher.io>, 
	Internals <internals@lists.php.net>, =?UTF-8?Q?C=C3=B4me_Chilliet?= <come@opensides.be>
Content-Type: multipart/alternative; boundary="00000000000025cb7a058f9c9026"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--00000000000025cb7a058f9c9026
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=D1=87=D1=82, 8 =D0=B0=D0=B2=D0=B3. 2019 =D0=B3. =D0=B2 16:42, Peter Kokot =
<peterkokot@gmail.com>:

> Hello,
> Thanks for sharing your stories about issues. Maybe we should start
> also thinking about the impact on the language attractiveness to pick
> it when starting a new web project since the core people can't come to
> conclusions how to make the language more consistent on the long run
> (PHP 9 etc)... With more and more ambiguities, inconsistencies,
> lockups, and dead ends behind the language there is probably also a
> bit of a factor to consider that it lowers this attractiveness.
> Meaning less people will think of adopting it (with all the things
> combined - short tags, that and that inconsistency not being removed
> from PHP due to major disastrous BC break there and there). So, the
> damage is also on the long run with more and more locks and dead ends
> not being able to be fixed and cleaned.
>
>
> --
> Peter Kokot
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Hello.

Peter above put my thoughts perfectly.

BC is great, but you need to pull the cord at some point. And the whole
short tag back and forth, with deprecation warning and stuff, has been
around for last half a decade. It is time to accept that it needs to go and
there should be no runtime dependent switch for this. Valid PHP tags are
`<?php` and `<?=3D` and that's it.
I really liked how language picked up the cleanup pace in the last few
years and it needs it. I finally see genuine interest in people to actually
either come back or pick it up instead of JavaScript (NodeJS) and other
fancy new shiny stuff. And a lot of it is because of the cleanup efforts
and WTF?! removal, the language having the option to be stricter (I was not
a fan of strict mode when it was coming up - now I don't use anything else
- it is AWESOME).
If the old guard starts to push back as much as I have seen here, we are
going to lose momentum as a community and have people not willing to work
on PHP as much. I mean anyone who has been on this list for more than 10
years should remember how it was in 5.0-5.4 days - slow, painful and
somewhat unfriendly, until a few major contributors kind'a muddled though
and pushed a few major changes that allowed the momentum to build up and
somewhat break the stalemate (and it did help that HHVM reared it's head
and had stroked a few egos the wrong way). I guess the curve repeats
itself, but we should make an effort to curb it and not revert back to "BC,
BC, BC!!!!" holding everything up.

Reality is, a lot of those "non-tech company" examples people give here has
nothing to do with language evolution. Yes, they are users, but we are not
responsible for the code they write, for the way they configure their web
servers and the way they can run a PHP4 server past 10 years and still have
no clue, because nobody cares or "it works, it makes money, no need to
invest". I would say that most of us on this list, if not everyone, are
smart enough to run/leave/not work for companies like that, so we are
somewhat shielded from that ignorance and just forget how bad it can be.

Long story short - indecision is not an option. The previous RFC has
passed. Everyone involved, I hope, understands that yes, there will be
stuff going wrong for some users who are careless and/or ignorant and live
under a rock. Can we really do anything about that? I would say no unless
we freeze the language and do nothing. I mean I have exposed my PHP code
during server setup by just forgetting to do `systemctl reload nginx`,
hitting the URL and getting my `index.php` on the screen more times than I
care to confess to.
Let's look into the future, use a reasonable amount of caution and/or
deprecation notice periods, but please stop trying to block features
"because stupid users". You give them the most secure software you can
write, they go change settings on their own and get p0wned/defaced/hacked
anyway even when you tell them not to do it and that y'r refusing to work
on their project because of decisions they make.

--=20
Arv=C4=ABds Godjuks

+371 26 851 664
arvids.godjuks@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius

--00000000000025cb7a058f9c9026--