Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:59554 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 92340 invoked from network); 9 Apr 2012 20:58:48 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Apr 2012 20:58:48 -0000 Authentication-Results: pb1.pair.com header.from=vchkpw@developersdesk.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=vchkpw@developersdesk.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain developersdesk.com designates 204.228.229.4 as permitted sender) X-PHP-List-Original-Sender: vchkpw@developersdesk.com X-Host-Fingerprint: 204.228.229.4 lessa.developersdesk.com Received: from [204.228.229.4] ([204.228.229.4:60735] helo=mail.developersdesk.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 69/CC-34074-58D438F4 for ; Mon, 09 Apr 2012 16:58:46 -0400 Received: (qmail 18310 invoked by uid 89); 9 Apr 2012 20:58:43 -0000 Received: from unknown (HELO ?10.1.1.5?) (vchkpw@developersdesk.com@67.61.98.111) by 0 with ESMTPA; 9 Apr 2012 20:58:43 -0000 Message-ID: <4F834D82.4030601@developersdesk.com> Date: Mon, 09 Apr 2012 14:58:42 -0600 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: internals@lists.php.net References: <-5877502932356715576@unknownmsgid> <-3647345967307864634@unknownmsgid> <4F831FAE.2030208@ralphschindler.com> <4775322189440202047@unknownmsgid> <4F833682.2000301@ralphschindler.com> <4F833AB0.2060306@sugarcrm.com> <4F8340E6.90005@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] RFC: source files without opening tag From: vchkpw@developersdesk.com (Rick WIdmer) On 4/9/2012 2:41 PM, Kris Craig wrote: >> > Honestly, I would suggest just getting rid of "Option 1" altogether. It > would end up over-complicating this to such a degree that any usefulness it > might serve would be considerably diminished. > > As for embedded HTML, if you allow the ?> tag in these .phpp files, then > that pretty much negates the entire purpose of having them to begin with. > Essentially, you'd just be changing it so that, instead of defaulting to > "?>" when no tag is present, it defaults to" value in that as a developer. > > A developer should *not* be including in a .phpp file classes that contain > HTML within the ?> tag, period. If they need to include something that has > that, they should do it in a regular .php file. An "HTML-less" PHP file > needs to be exactly that; no direct HTML allowed. Otherwise, the RFC is > completely and utterly pointless IMHO. > > > I think this would be awesome for PHP 6, but I'll have to vote against it > if you settle on using "Option 1" and/or allow ?> content to be > embedded/included in .phpp files. If we differentiate based solely on the > file extension and keep ?> tags out of it, then I'll definitely support it! Please forget about file extensions. PHP should not consider file extensions. The only reason .php files are executed by PHP is because the web browser is configured to pass that extension to PHP rather than handle it internally. I sincerely hope that any suggestion to eliminate the ability to use PHP as a template engine will be met with a veto by the core developers, or maybe even another suggestion by the trademark owner of PHP that he will not allow the PHP name to be used on such a language.