Request for Comments: Additional Parameters to Include and Require

• Version: 0.1
• Date: 2012-03-06
• Author: Michael Morris dmgx.michael@gmail.com
• Status: Under Discussion
• First Published at: http://wiki.php.net/rfc/changes_to_include_and_require

Proposed are a pair of changes to the file inclusion process, and the four language statements that process those includes - include, include_once, require, and require_once. The changes can be implemented together or independently. Throughout this RFC include is mentioned directly, but wherever it is mentioned the change applies to the other three.

A common beginner gotcha occurs the first time they attempt to use sessions or the header function. Whitespace outside the php tags is sent to the browser, and the first time this occurs its too late to start a session or make changes to the file header, so a warning is output.

This could be avoided if a PHP file could be written and accepted without an opening <?php tag (the closing tag can be omitted without affecting the parser - whether it should be is up for debate). For this to be possible PHP needs to be warned that this is going to occur. So a boolean argument is added to the include call. If not passed, or 'false' the legacy behavior of expecting a <?php tag to be in the file will be retained.

If 'true' is passed then the code is presumed to be PHP, at least until a closing tag is encountered.

Framework designers can more strongly enforce code separation. For example, if a coder attempts to jump to html output in what the framework expects to be a database interface class - which shouldn't need to output html - there would be a syntax crash caused by this. Again the obstinate coder could work around this with echo.

Is it worth the time to enforce the whole file be tag less? I would imagine on the implementation side doing what is discussed above would be as simple as appending “<?php” to the start of the text stream of the file, then let the parser proceed as normal. Also, echoing output would still be possible.

Would the engine run faster if it could parse the file without worrying about the <?php ?> tokens at all? Would the pickup be worth the time?

The largest problem is with IDE's. There is no current convention to warn them that the file is pure PHP. However, I think this can be mitigated by adopting an extension for php include files -- *.pif, *.iphp are two possibilities. However, the language itself doesn't need to give a care about this directly.

An addendum to this problem is the possibility of having PHP parse the file differently dependent on the extension. This is strictly speaking a BC break, but I don't imagine the scope would be large. Maybe a ini file extension to turn on tag less parsing for the listed extensions?

Currently files are always imported to the root namespace. The second suggestion is to allow a namespace to be passed as an argument to include. If a namespace is specified then the file is imported to that namespace. If the file has a namespace definition that namespace becomes a sub-namespace when imported.

The lesser use of this change is to allow php template files to not have to start with a namespace declaration. Since these files are meant to be used by designers the namespace declaration, which is business logic, feels out of place.

The larger implication of the change is that dynamic namespace resolution becomes possible. This is a powerful but potentially huge can of worms for the PHP programs that try to take advantage of this trick. Basically, instead of the namespace being hard coded into class definitions, a framework's autoloader can decide for itself which namespace to class requests into. Consider the following:

$db = new DB();

The autoloader gets “\DB” as it's argument. It could be programmed to look in an extensions or project namespace for a DB and if finds one, include it to the root namespace (assuming the file has no namespace definition itself). When it loads that file it would likely have this class declaration.

class DB extends Core\DB

So the autoloader would then load the Core DB class into the Core namespace since it could do so with

require ('path/to/core/DB.php', 'Core');

This provides a powerful layer of flexibility for frameworks. It also allows a tyro to whack their foot off and spaghetti doesn't even begin to describe the situation that will occur if this gets used incorrectly.

2012-03-06 - Initial proposal.