Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106422 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 72729 invoked from network); 7 Aug 2019 21:58:39 -0000 Received: from unknown (HELO tbjjbihbhebb.turbo-smtp.net) (199.187.174.11) by pb1.pair.com with SMTP; 7 Aug 2019 21:58:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=php.net; s=turbo-smtp; x=1565810738; h=DomainKey-Signature:Received: Received:MIME-Version:References:In-Reply-To:From:Date: Message-ID:Subject:To:Cc:Content-Type; bh=X0mbRwHQt90pOc9nl2pGoG TulxtE91MQmo1IMID34D0=; b=Fctp2RmxdFK4MG+ODZugVJMhTK9TotNBBsgYaD /iYJwD+ZuL0pzND/teIwmQShTPd8HbIFqnB8UQEXImdBhfx7ZxMrLBADTOf3B6un L5FKpDh/AQrMxz3yIsQ5zJJ/cDdTFYPHDfUQV38+56YeLov8sHTazxdXEDDHWW4N LK1L4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=turbo-smtp; d=php.net; h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type; b=U1osFO/qrhgoroNRn+pTxPy5QlQOpBXU3JIFGtR6K8qnQY/qTWKf083oA5y+Nv 5hAlQk6uws1pVJtHRwQqh0pP5Bw82N9hZSSeaFNBVrScEe9AzZZkvKuOpsQ06FYK zQfV4HSbaGUKWSLhgKYooM5asOlI+zcwetXLjC1scnu+c=; Received: (qmail 22468 invoked from network); 7 Aug 2019 19:25:37 -0000 Received: X-TurboSMTP-Tracking: 5209698258 X-Gm-Message-State: APjAAAWyraHN7uuso/SVeddyG3iMXN4mjDaPdTqbNlXcLvQxvSQfYego YHW5fDHi95ZuyTyjPXUf3ITML4WRa4SFmDQgASc= X-Google-Smtp-Source: APXvYqxeqpeFOhUEZBAh/h8s+tI9xrWIbFxI3DPFa+pBHPIk7Mjqv4t/5xwkXW9p5RSm2kKwAJ0bA6lQROBFoKlENZw= X-Received: by 2002:a37:4f82:: with SMTP id d124mr9174829qkb.23.1565205937215; Wed, 07 Aug 2019 12:25:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 7 Aug 2019 22:25:25 +0300 X-Gmail-Original-Message-Id: Message-ID: To: Peter Kokot Cc: Chase Peeler , Dan Ackroyd , Andrey Andreev , "G. P. B." , PHP internals Content-Type: multipart/alternative; boundary="000000000000e35e07058f8be76e" Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again From: zeev@php.net (Zeev Suraski) --000000000000e35e07058f8be76e Content-Type: text/plain; charset="UTF-8" On Wed, Aug 7, 2019 at 8:45 PM Peter Kokot wrote: > Considering that you're in favor of keeping the short opening tag in > PHP "forever" because you haven't added any kind of other solution > either by now neither you see an issue with this... I think the worst > situation for language is that there is an option to write non > portable code with this unfortunate short tag. Peter, To put it simply - many of us simply don't see an issue if short tags are with us even at PHP 99, centuries after we're no longer around. We certainly don't see an issue if it sticks with us until PHP 10. In fact, it's not that we don't think it's an issue - we actually think that's a Good Thing if it stays, and a Bad Thing if it's removed. I did my best to illustrate why I think that is the case in my Counterargument ( https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags). I accept that you see things differently. However, please accept that we also see things differently and are entitled to our opinion just as much as you are entitled to yours. We simply fail to see an issue with short tags that comes even close for us to want to remove it. It's not even a close call. A zero gain and substantial pain associated with a deprecation should be an obvious choice. To quote Sara Golemon: "Frankly, I can't understand why anyone *does* want to drop it." (https://twitter.com/SaraMG/status/1158936328450576384) PHP always had a bias for downwards compatibility. We went out of our way to come up with creative ways to reinvent the brain of the language several times - while going through hoops to keep code behavior identical. We did not shy away from breaking compatibility when there was a very strong case - such as the OO model between PHP 4 and 5, the deprecation of magic quotes and the deprecation of safe mode - all painful migrations, but with a very, very strong case that goes well beyond "having more than one way of doing things" or "this creates the possibility of non-portable code". TBH, I expected folks who are joining the project to accept that, although I guess I was naive as this is clearly not happening (it's only implied in the 'rules', but not actually codified). Repeating what I said a couple of weeks ago - it seems we've now switched to the business of breaking things almost for the sake of breaking things, and it's really disheartening. Many of us think that removing short tags does *absolutely nothing* to improve the portability of PHP code. I'll go beyond that - the ability to create non-portable code should never be grounds by itself for deprecating a feature (it can be a contributing factor). There are endless elements that an app can use that can make it non portable. For example, should we be deprecating support for all databases other than SQLite? After all, they may not always be installed. Should we deprecate the SHM extension? People using it may be stuck if they ever try to deploy to Windows. What about deprecating disable_functions? It's a portability disaster that's just waiting to happen. And I barely even got started. Almost anything beyond pure PHP logic may not work in all environments, and it's absolutely fine. It also constitutes absolutely no grounds for starting to go around axing features. Thankfully, fact is, not all code has to be portable. The important thing is that those who want to write portable code will be able to do so - while not forcing everyone else to write portable code by enforcing the lowest common denominator. I think Chase alluded to the fact that there's substantial anecdotal evidence that the availability of short tags did not actually cause any trouble in the last 20 years. And when I say anecdotal evidence - I mean that some of the most popular applications on the Web (including the top 3 most popular ones) have been written in PHP, and there's a gigantic framework ecosystem around PHP. I realize that you think it's a problem that we have two opening tags for PHP - and a major one at that. It's entirely your right to do so and I wholeheartedly accept it. Similarly, please accept it that I, as well as many others, simply don't view this as a problem. And when one does not think there's a problem, one typically does not spend time finding solutions. FWIW, if for whatever reason I did think it was a problem - I think the updated V2 RFC would be the best way to solve it. But I don't. With all that said, I still think there may be a solution that can make mostly everyone happy, or at least not really unhappy. It may even include deprecating short tags (in a way) - but more importantly - overhauling much more important elements in PHP as well. I hope to bring it up for some initial brainstorming (not RFC level, just gauging response) tomorrow. Zeev --000000000000e35e07058f8be76e--