Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59699
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain punkave.com designates 209.85.213.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CBAA19C5.12045%luke@cywh.com>
References: <CAORXhGK47pRN8uUTENqSbddQoCP8VopomPhJW7N2pN6ZU8vNPQ@mail.gmail.com>
	<CBAA19C5.12045%luke@cywh.com>
Date: Tue, 10 Apr 2012 21:58:45 -0400
Message-ID: <CAORXhGLtiHzr=M1-dUz4pWavN2VNDktE1Nq_Qvk-N-8=iVoVCQ@mail.gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] UPDATED RFC version 1.1: source files without opening
 <?php tag
From: tom@punkave.com (Tom Boutell)

On Tue, Apr 10, 2012 at 8:19 PM, Luke Scott <luke@cywh.com> wrote:
> - 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?

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')?

> - 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 would like to be able to specify the mode as an environmental variabl=
e
> from the web server, perhaps "PHP_MODE". So I could do something like thi=
s
> in my Nginx config:
>
> location / {
> =A0 =A0fastcgi_pass =A0 unix:/Server/tmp/php-fpm.sock;
> =A0 =A0include =A0 =A0 =A0 =A0fastcgi_params;
> =A0 =A0fastcgi_param PHP_MODE "pure";
> =A0 =A0fastcgi_param =A0SCRIPT_FILENAME =A0 =A0 =A0$document_root/index.p=
hp;
> =A0 =A0fastcgi_param =A0SCRIPT_NAME =A0 =A0 =A0 =A0 =A0/index.php;
> =A0 =A0fastcgi_param =A0HTTP_ACCEPT_ENCODING "";
> =A0 =A0fastcgi_param =A0HTTPS $https;
> =A0 =A0 =A0 =A0}

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?

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.

--=20
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com