Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:59561 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 3300 invoked from network); 9 Apr 2012 21:32:09 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Apr 2012 21:32:09 -0000 Authentication-Results: pb1.pair.com smtp.mail=kris.craig@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=kris.craig@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender) X-PHP-List-Original-Sender: kris.craig@gmail.com X-Host-Fingerprint: 74.125.82.54 mail-wg0-f54.google.com Received: from [74.125.82.54] ([74.125.82.54:46386] helo=mail-wg0-f54.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 3E/1F-34074-655538F4 for ; Mon, 09 Apr 2012 17:32:08 -0400 Received: by wgbdq13 with SMTP id dq13so3616253wgb.11 for ; Mon, 09 Apr 2012 14:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zLSdR2KoJsDVrBJ3nOOBAV2bvMWx6/aDEoxC0fxNoXc=; b=P76GpN2NY2R+KvoaraItB0x4MzDKRZcKKHwKD8u4P8CN+UsVYCBhTU62qtcHFmSHoF 4qkRmE2ZXfWJClrj/qa8YTp8Gg/LwY3N1LihdLiNN423vjRGwBY7PfIcHRwDEMtkoGSE KH37pGjkfojGdECqgF2ePQ73BziqljiPYPwALUmNUEghZnzcM9+3YkyTLh0H1Kj6aHWu hllvCbCUl/lKM5IPBDNlIfIvTOR6iqN9QHCumVA219UrncLNn5TvTShyzggv6OnwcrsI rJnGxLP/eo66q+Ed77PuC4UyLoe3HLztmUWN2jo13lrK/BvPlwSJzxvH4rnseByx3JUf Su6Q== MIME-Version: 1.0 Received: by 10.180.95.197 with SMTP id dm5mr1123090wib.20.1334007123983; Mon, 09 Apr 2012 14:32:03 -0700 (PDT) Received: by 10.223.79.67 with HTTP; Mon, 9 Apr 2012 14:32:03 -0700 (PDT) In-Reply-To: References: <-5877502932356715576@unknownmsgid> <-3647345967307864634@unknownmsgid> <4F831FAE.2030208@ralphschindler.com> <4775322189440202047@unknownmsgid> <4F833682.2000301@ralphschindler.com> <4F833AB0.2060306@sugarcrm.com> <4F8340E6.90005@sugarcrm.com> <4F834D82.4030601@developersdesk.com> Date: Mon, 9 Apr 2012 14:32:03 -0700 Message-ID: To: Tom Boutell Cc: PHP Internals Content-Type: multipart/alternative; boundary=f46d04447f47c0bb4c04bd45bc2d Subject: Re: [PHP-DEV] RFC: source files without opening tag From: kris.craig@gmail.com (Kris Craig) --f46d04447f47c0bb4c04bd45bc2d Content-Type: text/plain; charset=ISO-8859-1 Lol true dat. You convinced me on the file extension, so as far as I can tell that just leaves us with the tag itself as the viable approach. =) --Kris On Mon, Apr 9, 2012 at 2:24 PM, Tom Boutell wrote: > I'm not sure you're wrong about this, but it's definitely an ironic > suggestion (: > > On Mon, Apr 9, 2012 at 5:22 PM, Kris Craig wrote: > > > > > > On Mon, Apr 9, 2012 at 2:03 PM, Tom Boutell wrote: > >> > >> As others explained before the RFC was drafted, file extensions should > >> not be directly respected by PHP because environments differ too much. > >> Instead a convention, NOT enforced at the code level, would be > >> published and encouraged: .phpc for files that start out in PHP mode, > >> and .php for files that start out in HTML mode. PHP would NOT enforce > >> this, it would just be an encouraged practice in the writing of > >> autoloaders and so on. (Note that autoloaders are already concerned > >> with file extensions. They have to be in order to transform a class > >> name into a filename.) > >> > >> The RFC does not call for putting an end to the traditional use of PHP > >> for templates at all, that is still the default behavior when parsing > >> PHP. There is an entirely separate RFC that calls for that, but that's > >> another thread. > >> > >> On Mon, Apr 9, 2012 at 4:58 PM, Rick WIdmer > >> wrote: > >> > 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" >> >> any > >> >> 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. > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > -- > >> > PHP Internals - PHP Runtime Development Mailing List > >> > To unsubscribe, visit: http://www.php.net/unsub.php > >> > > >> > >> > >> > >> -- > >> Tom Boutell > >> P'unk Avenue > >> 215 755 1330 > >> punkave.com > >> window.punkave.com > >> > >> -- > >> PHP Internals - PHP Runtime Development Mailing List > >> To unsubscribe, visit: http://www.php.net/unsub.php > >> > > > > Hmm yeah I see your point. Requiring a separate file extension would > force > > configuration changes to the webserver. And since not everybody has > access > > to that, it would mean that any projects that contain these files would > not > > be able to run on hosts like that. > > > > Ok you've convinced me on the file extension issue, just based on that. > But > > I still don't like the new require_* keywords or allowing ?> to be > mixed-in > > with PHP scripts that are supposed to be pure code. Again it just comes > > down to a question of usefulness and creating a solution in search of a > > problem. > > > > What we need is a way to tell the parser that this file is pure PHP. We > > can't use the file extension, so it has to be at the code level. If I'm > > interpreting your proposals correctly, it looks like your approach would > be > > to have the including file make this determination. Personally, I think > we > > should do the opposite; i.e. this should be defined in the PHP file > itself. > > > > Obviously, it would need to be at the top of the PHP file (whitespace > > notwithstanding). Since we don't want any BC breaks, we at very least > need > > it to start with " wasn't > > mean to be parsed. So how about we keep it simple and just use a single, > > " would be allowed after > that. > > Anything before that (in the file itself) would also be ignored and > throw a > > warning. > > > > This sounds like the best approach, given the limitations involved with > > webserver configurations. I'm still very much against though allowing ?> > > within one of these files (included or otherwise), as it really defeats > the > > whole purpose and would just encourage poor architecture without any > > countervailing benefit. > > > > --Kris > > > > > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > --f46d04447f47c0bb4c04bd45bc2d--