Most people would probably use this for libraries at first, when working with frameworks that are not designed to have all their code explosed in the document root anyway. Adoption for direct execution on the webserver would happen more gradually.
On Wed, Apr 11, 2012 at 4:14 PM, Luke Scott <l...@cywh.com> wrote: > 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 -- 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
