Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106426 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 85456 invoked from network); 7 Aug 2019 22:45:15 -0000 Received: from unknown (HELO cache4.mydevil.net) (213.189.55.195) by pb1.pair.com with SMTP; 7 Aug 2019 22:45:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=korulczyk.pl; s=devil; h=Content-Transfer-Encoding:Content-Type:In-Reply-To :MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=cW/ZBUApeRDBVrj97ElM47w++htrWNDVC5Q/BaQXk0A=; b=OgCsC3jvknm99VngOB0pq+XFhN G6P3PCmVvYOjfHpQCen02GYAWgB9mUylTTu3hvxyFYyP2UZHlErP0rXtAQXfFwleTyKiuhCpZ0N11 7LAaJwCBeiSMIyDM5JxPco3rvj7EP1NWEFWsfddh2GK8UzaYEXd4nYnBG1dxWxmyHkU0=; To: internals@lists.php.net References: Message-ID: <17ac3334-42ab-20d6-e4b1-b3bbfc425804@korulczyk.pl> Date: Wed, 7 Aug 2019 22:12:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-AV-Check: Passed X-System-Sender: robert@korulczyk.pl Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again From: robert@korulczyk.pl (Robert Korulczyk) > PHP is, after all, built almost entirely on extensions. Those extensions can either be there, or not, enabled in the INI, or not. Do we consider code > written containing functions from mysqli, gd or zip (just to name a few) to be non-portable because we can omit them from the INI (or just not install > them). These are completely different things. In case of extensions, you can check whether the extension is installed, you can react on lack of it, and you can require extension as part of composer constraints (sometimes you can just use polyfill). And at worst case, you will get a fatal error that will tell you that there is something wrong with your code/environment. Neither of it is true for short tags - your code is just silently displayed. And you can't do anything about it, because you're code is no longer a code. > IMHO short tag removal has one major thing going for it, consistency, and by extension, predictability. > > That's it. For me, the main reason to remove short tags are code leaks. As long as there will be an option to disable short open tags support, there will be code leaks. Now there is a chance to remove one source of WTFs in PHP and end this code leaks problem once and for all. The migration may be problematic for fraction of applications, but at least this is a one-time process, well documented and preceded by a long deprecation period. The alternative is current state when code leaks just unexpectedly pop out without any warning and explanation (exception "It's PHP, deal with it"). Regards, Robert Korulczyk