On Apr 11, 2012, at 12:02 PM, Chris Stockton <chrisstockto...@gmail.com> wrote:
> Hello, > > On Wed, Apr 11, 2012 at 11:47 AM, Luke Scott <l...@cywh.com> wrote: >> >> The .php extension really isn't used by PHP, but it's used by a web server >> to identify PHP code and send it to the interpreter. Any mention of file >> extensions in the RFC would have to be nothing more than a recommendation. >> I do understand that if a .php file didn't have a starting <?php it could >> unintentionally get printed... But it's nothing we can really gurantee. >> That's why "template mode" has to remain the default. However, I think >> it's prudent to provide an environmental variable to let the web server >> choose what mode to use. That way you can instruct Apache/Nginx to >> interpret .phpc as "pure code mode" and ".php" as the current "template >> mode". >> >> The most exciting thing for me in this RFC is disallowing the use of ?>. A >> starting <?php should be optional for portability, as long as it comes >> first. I wouldn't be opposed to making the starting <?php required in code >> mode, but that's not what Tom wants. I just want a mode where you don't >> have ?>...<?php somewhere in the middle. I occasionally see this, and it >> just leaves me with a WTF moment (After all we have heredoc/nowdoc). >> > > I very much understand how the extension relates to various web > servers. The thing is every single distribution, rpm, deb package etc > that shared servers and private repos have around the world are > configured to use .php. If PHP Version X. releases with a new feature > advocating the use of a new extension a burden is placed on those > various distributions and package maintainers for security reasons to > add this new extension to the web server configurations. Who / how is > that being communicated to them? That is why a RFC including > extensions as a convention seems a little off / unsafe for me. Again > not something I feel strongly about, but something to be considered. True. Which is why I would add <?php on top of all my files regardless of mode and give it a .php extension. Tom, on the other hand might give his files a .phpc extension with no starting <?php. It would be up to him to configure his web server to recognize that (by either sending it to PHP as code mode, or sending a 403 forbidden). The additional extension could be nothing more than a recommendation. Even if these modes came out tomorrow doesn't mean people are going to start stripping <?php tags from their source files and changing their extensions. If they did I'm sure they'd make sure their web servers were configured for it. Adoption will take time. > >> When I use get_defined_constants(TRUE); I didn't see any PHP_ constants. >> There are many built in constants that don¹t' follow this rule, and follow >> their own conventions. T_* for example is reserved for tokens. If this is >> indeed a requirement, I don't mind as long as these constants aren't >> insanely long. But if it's not a requirement, I'd prefer not to have the >> PHP_*. It's a bit redundant. >> > > Most extensions have their own constant space The T_* space parser > tokens are listed in the documentation and are registered under the > tokenizer space. Some other extensions might may not be highly > consistent with how they prefix their constants, that is up to the > developer of the extension. However include/require are reserved words > and part of the php core, as such it would make sense to me that they > would be registered under the core constant name space which is mostly > understood as PHP_. No reason this couldn't be deviated from, as > UPLOAD_* and ZEND_* have their own spaces, but INCLUDE_* seems pretty > generic to reserve and seems safer under PHP_* to me. This is a small > detail I don't feel strongly about, but it is a detail that should be > considered. Yeah, i'm not sure. Would like for more people to chine in. Its more cosmetic though. I just would prefer it not to be sinething like: PHP_INCLUDE_PURE_PHPCODE. It's a lot to type! Also long keywords make it difficult to stick to 80 characters per line. Luke -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
