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. > 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. -Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
