UPDATED RFC version 1.1: source files without opening <?php tag View as Markdown

Tom,

Much better, though I'm still very troubled by allowing non-pure PHP
code to
be mixed-in with pure PHP (by means of includes). The problem I have
with
this, as a developer, is that this means I can't really trust that what I
will get from a "pure PHP" script will actually be pure PHP, because
non-pure scripts lower in the stack might mix-in HTML code that would
then
get passed up through the stack. These really shouldn't be mixed
anyway, so
I'm just not seeing any value in not keeping this separation consistent.

The approach you suggest would make it impossible to load an existing
library of perfectly good classes from a newer framework. I don't know
anyone who would be able to get work done under those circumstances (:
It would lead to almost no adoption of the new feature.

This shouldn't be used to load libraries that dump raw HTML output! That
literally defeats the entire purpose. You're also assuming that all PHP
developers do 100% of their coding through pre-existing frameworks.

If you're including a library that contains embedded HTML, you should do so
from a regular .php file. Then you can include the .phpp file at that same
level, thereby avoiding the collision.

For example, here's what you're suggesting:

-------------- (Main Script) ------------
| |
| |
[Included .php/HTML Script] {Included .phpp Script}
|
|
[Included .php/HTML Script from Framework/Library]

That approach is bad architecture and simply unnecessary. If you want to
interface with that library, do it like this instead:

            (Main Script)
                 |
                 |
     [Included .php/HTML Script]
         |                   |
         |                   |

{Included .phpp Script} [Included .php/HTML Script from
Framework/Library]

In other words, instead of calling that third-party, HTML-containing
library from the .phpp file, call both it and the .phpp file from a regular
.php file, which will then act as the "controller" and bridge the
functionality between the two. This would be a far more sane architecture,
anyway. And it allows you to achieve the exact same result, without having
to have included HTML bits polluting the upstream from the pure PHP stack.

Make sense? I'm just not seeing any value in breaking this model just so
that bad, lazy architecture that shouldn't be used in the first place can
be supported.

Whereas if we make this feature easy to adopt, and strict within the
files it does apply to, then over time we would see more and more
.phpp and less and less .php. Mission accomplished. Sometimes a
realistic compromise is the long term way to get to a better place.

Think through what will likely happen in the real world under various
proposals, and not just what would be most pure (:

See above. =)

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

• I would like to see an INCLUDE_SILENT method to prevent warnings from
  being thrown with include/include_once statements. Currently doing
  something like @include "/path/to/file.php"; not only hides these
  warnings, but warnings/errors/notices thrown by the file itself. An
  INCLUDE_SILENT flag would be extremely helpful in some situations.

I almost included this, but wasn't sure how you would actually become
aware of the error at that point. class_exists is probably a valid
answer to that. It would be dangerous to use the INCLUDE_SILENT for
any include file that wasn't a class. The return value of 'include' is
the return value of the code it executed, so we can't use that. How
about INCLUDE_EXCEPTION?

That would be slightly better as you could then catch the exception.
But it doesn't make sense to do this in an auto loader because you'll
always be including classes. It would also add unnecessary overhead
having to catch the exception.

For me INCLUDE_BOTH is absolutely necessary.

Why not add both?

This is really a separate issue, but it's true it would make a lot of
sense to add this bit at the same time.

• The INCLUDE_ONCE and INCLUDE_ERROR_ON_FAILURE are a bit redundant.
  Wouldn't you just use require or include_once/require_once?

I like being able to do things dynamically without writing a switch
statement. As we move toward having more bit flags, why not have the
option of using flags for the existing distinctions as well (as long
as you start with plain old 'include')?

I'm not sure it can be dynamic being a construct.

• Not sure I like the word "pure code". I would prefer just "code" -
  INCLUDE_CODE. Perhaps even just "pure" - INCLUDE_PURE. I just don't like
  two words. Would also like another flag for the other mode, such as
  INCLUDE_TEMPLATE or INCLUDE_EMBED.

These are bits, so INCLUDE_TEMPLATE would just be zero. Not sure it
makes sense to have that as an explicit flag.

I suppose that makes sense. Still, could define it as zero.

• I would like to be able to specify the mode as an environmental variable
  from the web server, perhaps "PHP_MODE". So I could do something like this
  in my Nginx config:

location / {
fastcgi_pass unix:/Server/tmp/php-fpm.sock;
include fastcgi_params;
fastcgi_param PHP_MODE "pure";
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
fastcgi_param SCRIPT_NAME /index.php;
fastcgi_param HTTP_ACCEPT_ENCODING "";
fastcgi_param HTTPS $https;
}

I almost included this too but I am a little fatigued thinking about
all the details (:

Can we arrange it so that .php and .phpp each do the right thing under
fastcgi without creating two process pools? Is configuring FPM similar
to configuring the classic CGI SAPI for FastCGI operation?

In order for it to work you need an environmental variable. You can
use the same pool, Nginx just needs a way to tell PHP what mode to use
for what extension.

In my case I'd configure Nginx to send all requests to Index.php in
pure mode, as I have shown in my config sample.

A -p option for CLI and plain CGI is simple enough at least.

I personally don't mind all that much if entry point PHP files don't
get this feature but of course I see that others would like it. And
one day it would be nice to alias phpp to php -p and write PHP one-off
scripts without <?php.

Don't forget to mention "pure" mode can optionally start with <?php as
it's the first token.

Luke

Hello,

On Wed, Apr 11, 2012 at 1:48 PM, Chris Stockton
chrisstocktonaz@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.

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.

-Chris