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
