On Apr 10, 2012, at 6:59 PM, Tom Boutell <t...@punkave.com> wrote:
> On Tue, Apr 10, 2012 at 8:19 PM, Luke Scott <l...@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?
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
