On 4/11/12 11:27 AM, "Chris Stockton" <chrisstockto...@gmail.com> wrote:
>Hello, > >On Wed, Apr 11, 2012 at 11:14 AM, Tom Boutell <t...@punkave.com> wrote: >> On Wed, Apr 11, 2012 at 1:48 PM, Chris Stockton >> <chrisstockto...@gmail.com> wrote: >>> I have read the RFC and I although from what I gather it seems that >>> .phpp is a recommendation and not a requirement, but I want to make >>> absolutely sure. >> >> >> That is correct, it is not a requirement. However if you know of any >> reason why .phpp would be a bad choice of file extension for PHP >> source files without <?php and ?> in them, now would be a good time to >> share that input. >> > >Something about PHP advocating it makes me feel a little uneasy, I >guess it can at least help frameworks have a unified standard for >their auto loaders etc. My main concern is people expecting .phpp will >"just work" when including via apache on shared hosting servers etc. >End up with a file full of code, passwords, who knows what downloaded >or displayed in a browser. The burden of responsibility here is not >entirely clear for me, but I am just not sure I like proposing a >separate PHP extension, just seems a little wrong. However from what I >see no one else has said anything so perhaps I am wrong. I will say if >I was developing a framework I might try to think of other >alternatives for my auto loading / detecting of pure php files. I.E.a >specific folder like "purephplib" a specific portion of the file name >or something like "Class_Name_Pure" (like this much less then folders, >but I think more then a file extension. Just my two cents. 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). > >>> My only other issue is that we are not really following the guidelines >>> for reserved constants, since "include" is not part of a "include" >>> extension and a actual language construct it feels like it should live >>> inside the reserved PHP_* constants. There may be projects that make >>> use of "INCLUDE_ONCE" as a constant or maybe not, regardless I think >>> it should follow the documented naming guidelines to be safe. >> >> I wasn't aware of those guidelines. This makes sense to me. >> PHP_INCLUDE_ONCE, then? >> > >I will let others comment here, was just my initial thoughts. 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. Luke -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
