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
