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 <t...@punkave.com> 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 <kris.cr...@gmail.com> wrote: > > > > > > On Mon, Apr 9, 2012 at 2:03 PM, Tom Boutell <t...@punkave.com> 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 <vch...@developersdesk.com> > >> 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"<?php". I just don't see > >> >> 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 "<?" so that we don't end up parsing anything that > wasn't > > mean to be parsed. So how about we keep it simple and just use a single, > > "<?phpp" at the beginning of the file? No ?> 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 > >
