Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:59702 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 49471 invoked from network); 11 Apr 2012 02:56:38 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Apr 2012 02:56:38 -0000 Authentication-Results: pb1.pair.com smtp.mail=luke@cywh.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=luke@cywh.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain cywh.com from 209.85.220.170 cause and error) X-PHP-List-Original-Sender: luke@cywh.com X-Host-Fingerprint: 209.85.220.170 mail-vx0-f170.google.com Received: from [209.85.220.170] ([209.85.220.170:61223] helo=mail-vx0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 8E/1D-18401-6E2F48F4 for ; Tue, 10 Apr 2012 22:56:38 -0400 Received: by vcbfo14 with SMTP id fo14so388322vcb.29 for ; Tue, 10 Apr 2012 19:56:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=M1i+2fczn9Cc51ADp2kYYhKeNlbpM6s0tofJdvwFdbE=; b=GP/MQobbCD2dlbLZHWIC6BN9UN0twQ3LvNH51a+yllNNeshw3OkiCmzvj0vk9Lf1Ly ULaVg7d/pgP0Gy8nBkfBQbkzEPQLkbwqRASIZgtdnP3fZ1Yqg0XvkqNKb2y+msJh4kJ/ P+z5rA5RRFAblH6w4xkRXCSMGBDPhWeU8UasUGrIsinhKb6kGrRZ4K9B90oev5ICnClo cWZVRzra8bDGvYtRFh8AOw8R0MMr814GYXeuqmAqNeImRyiumVPWB0nYRqcwBBVwirkP rsSMFHssWpiO/WWsABBtGlopyjzqE2R8vZZ4iewtAwb0+QvtFDL1qg3I0ueiIoWLhjnS /MQg== Received: by 10.220.141.84 with SMTP id l20mr7021573vcu.31.1334112995421; Tue, 10 Apr 2012 19:56:35 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Date: Tue, 10 Apr 2012 19:56:34 -0700 Message-ID: <6050087184005303868@unknownmsgid> To: Tom Boutell Cc: PHP Internals Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnsHOYoZ/RYv9+4OQXEWbBw+XKYrZBX/+9X18fke7XaH9nZVsDjG+5sCXMhqv6uNTnHk2Ua Subject: Re: [PHP-DEV] UPDATED RFC version 1.1: source files without opening wrote: > On Tue, Apr 10, 2012 at 8:19 PM, Luke Scott 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