[PHP-DEV] Re: RFC: source files without opening tag
I would like to clarify what this RFC actually says. Let's try to keep
this thread to the pros and cons of this specific proposal.
The following new keyword would be introduced:
require_path
This keyword has two parameters of which the second is optional. The
first parameter is the path (filename or URL) to be required, and
behaves exactly as the sole parameter of the require keyword behaves.
The second parameter is an associative array.
If this second parameter is absent, require_path behaves exactly like require.
If the second parameter is present, the following keys may optionally
be present in the array, with the following effects:
If 'once' is present and true, the specified path is loaded no more
than once, exactly like require_once.
If 'warn' is present and true, a loading or compilation error results
in E_WARNING (per the current behavior of the include keyword). If
warn is absent or false, a loading or compilation error results in
E_COMPILE_ERROR (per the current behavior of the require keyword).
If 'code' is present and true, the parser begins reading the file as
if a ?php open tag had already been encountered. If code is absent or
false, the parser reads the file beginning in “HTML mode,” exactly as
the require keyword does today.
Examples:
// Behaves just like require
require_path 'filename.php';
// Behaves just like include_once
require_path 'filename.php', array('warn' = true, 'once' = true);
// Loads a file starting out in PHP mode so the opening ?php is not required
require_path 'filename.php', array('code' = true);
In addition, a convention (not a requirement checked by the code)
would be encouraged: PHP source code files without an initial ?php
would be named with a .phpc file extension.
That's all the RFC calls for. The rest of it is just responses to
frequently raised concerns:
https://wiki.php.net/rfc/source_files_without_opening_tag
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC: source files without opening tag
On 09/04/12 13:29, Tom Boutell wrote: I would like to clarify what this RFC actually says. Let's try to keep this thread to the pros and cons of this specific proposal. The following new keyword would be introduced: require_path I don't like the keyword name. Too confusing with the include_path configuration option for something very different. What about require_file ? This keyword has two parameters of which the second is optional. The first parameter is the path (filename or URL) to be required, and behaves exactly as the sole parameter of the require keyword behaves. The second parameter is an associative array. Does it require brackets? If 'warn' is present and true, a loading or compilation error results in E_WARNING (per the current behavior of the include keyword). If warn is absent or false, a loading or compilation error results in E_COMPILE_ERROR (per the current behavior of the require keyword). What if I want to silently ignore a missing-file condition? Ie. no warning or compile error if there file is not there (presumably to skip the need of a file_exist), yet receive all warnings generated by the included code. What about 'missing'= 'error' / 'warn' / 'ignore' ? If 'code' is present and true, the parser begins reading the file as if a ?php open tag had already been encountered. If code is absent or false, the parser reads the file beginning in “HTML mode,” exactly as the require keyword does today. I think reading the file as if a ?php open tag had already been encountered should add with the exception that an explicit ?php exactly at the beginning of the file is not a parse error but silently ignored. Best regards -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC: source files without opening tag
Option 1: Introduce require_path I think require_code is a better name. Parm 1 isn't a path, it is a file, so require_path seems wrong to me. I'd prefer a 'start in code mode' optional second parameter to include[_once] and require[_once]. Option 2: Filename Convention The PHP engine should not know or care what the file extension is. I won't object if you can convince autoloader authors to follow the .phpc convention. Personally, once I can count on this feature, every file I include/require will probably be written starting in code mode and using the new calling convention. Even when I use PHP to create page templates... Additional suggestions: Add an option so the CLI can start in code mode too. Add another Handler to the Apache SAPI, maybe application/x-httpd-php-code similar to x-httpd-php and x-httpd-php-source, so we can configure Apache to start arbitrary file extensions with code mode on. This defers setting the action for various file extensions to the person configuring the web server. Other web server SAPIs will need similar treatment, but I'll leave them to someone with personal experience. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC: source files without opening tag
On Mon, Apr 9, 2012 at 9:16 AM, Rick WIdmer vch...@developersdesk.com wrote: Option 1: Introduce require_path I think require_code is a better name. Parm 1 isn't a path, it is a file, so require_path seems wrong to me. Yeah, you're not the first to say this. require_file and require_code have both been suggested. I'm fine with either really. I'd prefer a 'start in code mode' optional second parameter to include[_once] and require[_once]. That would be fine as far as my goals here go, but I'm concerned that we'll just repeat this discussion if any other options for requiring things come into being (: Option 2: Filename Convention The PHP engine should not know or care what the file extension is. I won't object if you can convince autoloader authors to follow the .phpc convention. Personally, once I can count on this feature, every file I include/require will probably be written starting in code mode and using the new calling convention. Even when I use PHP to create page templates... Sounds like you're basically OK with that bit. Additional suggestions: Add an option so the CLI can start in code mode too. Add another Handler to the Apache SAPI, maybe application/x-httpd-php-code similar to x-httpd-php and x-httpd-php-source, so we can configure Apache to start arbitrary file extensions with code mode on. This defers setting the action for various file extensions to the person configuring the web server. Other web server SAPIs will need similar treatment, but I'll leave them to someone with personal experience. I'm not opposed to these suggestions. I was trying to keep it conservative and simple to implement and focus on the case where it bugs me (creating libraries of class files), but I'd be happy to see a way for .phpc to be the entry point / frontend controller / standalone script as well. As you say it must be done with SAPI options (the CLI included), not hardcoded file extension checking. -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC: source files without opening tag
IDE creators will definitely be excited with this new feature. 2012/4/9 Tom Boutell t...@punkave.com On Mon, Apr 9, 2012 at 9:16 AM, Rick WIdmer vch...@developersdesk.com wrote: Option 1: Introduce require_path I think require_code is a better name. Parm 1 isn't a path, it is a file, so require_path seems wrong to me. Yeah, you're not the first to say this. require_file and require_code have both been suggested. I'm fine with either really. I'd prefer a 'start in code mode' optional second parameter to include[_once] and require[_once]. That would be fine as far as my goals here go, but I'm concerned that we'll just repeat this discussion if any other options for requiring things come into being (: Option 2: Filename Convention The PHP engine should not know or care what the file extension is. I won't object if you can convince autoloader authors to follow the .phpc convention. Personally, once I can count on this feature, every file I include/require will probably be written starting in code mode and using the new calling convention. Even when I use PHP to create page templates... Sounds like you're basically OK with that bit. Additional suggestions: Add an option so the CLI can start in code mode too. Add another Handler to the Apache SAPI, maybe application/x-httpd-php-code similar to x-httpd-php and x-httpd-php-source, so we can configure Apache to start arbitrary file extensions with code mode on. This defers setting the action for various file extensions to the person configuring the web server. Other web server SAPIs will need similar treatment, but I'll leave them to someone with personal experience. I'm not opposed to these suggestions. I was trying to keep it conservative and simple to implement and focus on the case where it bugs me (creating libraries of class files), but I'd be happy to see a way for .phpc to be the entry point / frontend controller / standalone script as well. As you say it must be done with SAPI options (the CLI included), not hardcoded file extension checking. -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
