Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106443
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> <CAL0xaBFUiNAPCnz=rAi8w95SqWP0ZrMZQOkSt3TQaf6=dg+tVQ@mail.gmail.com>
In-Reply-To: <CAL0xaBFUiNAPCnz=rAi8w95SqWP0ZrMZQOkSt3TQaf6=dg+tVQ@mail.gmail.com>
Date: Thu, 8 Aug 2019 11:42:41 -0400
Message-ID: <CAPKYkKw0Eq5vhJX+JesEwjbJTJseyNKnWeGoCFWV3Dogj9w9pQ@mail.gmail.com>
To: Arvids Godjuks <arvids.godjuks@gmail.com>
Cc: Peter Kokot <peterkokot@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="0000000000002e210f058f9ce98f"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
From: chasepeeler@gmail.com (Chase Peeler)

--0000000000002e210f058f9ce98f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Aug 8, 2019 at 11:18 AM Arvids Godjuks <arvids.godjuks@gmail.com>
wrote:

> =D1=87=D1=82, 8 =D0=B0=D0=B2=D0=B3. 2019 =D0=B3. =D0=B2 16:42, Peter Koko=
t <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 a=
nd
> 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 actual=
ly
> 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 n=
ot
> a fan of strict mode when it was coming up - now I don't use anything els=
e
> - 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 "B=
C,
> BC, BC!!!!" holding everything up.
>
> Wait, how could positive progress have been made while short tags still
existed?


> 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 ar=
e
> 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 stil=
l
> 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 liv=
e
> 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.
>
You're in the "all or nothing" logical fallacy. You are acting as if being
against the removal of short tags is the same as being against any BC break
at all. As we've said MANY times, BC breaks aren't the issue. THIS
PARTICULAR BC BREAK IS THE ISSUE. It provides little to no positives to the
users and does very little, if anything, to improve the language. At the
same time it WILL lead to a very big barrier in terms of the ability to
upgrade for a large number of users.



> 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.
>
> Actually, most BC breaks, including this one, seem to be focused on
preventing issues from "stupid users." We're saying that short tags are bad
because of reasons. We can't trust users to not use short tags as long as
they exist, so we must force them to stop using them, no matter how painful
that might be. That's actually an OK thing to do if the reasons for doing
so justify it. I have yet to see the justification. All I've seen is people
attempt to mitigate the cost of the break, or, say the cost doesn't really
matter.



> --
> Arv=C4=ABds Godjuks
>
> +371 26 851 664
> arvids.godjuks@gmail.com
> Skype: psihius
> Telegram: @psihius https://t.me/psihius
>


--=20
Chase Peeler
chasepeeler@gmail.com

--0000000000002e210f058f9ce98f--