Request for Comments: Additional Parameter for 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

Change include, include_once, require and require_once to take a second optional string argument.

require( 'path/to/file.php', ['namespace\to\attach\file'] );

Currently files are always imported to the root namespace. The suggested change is to allow a namespace to be passed as the second 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. If no namespace is specified the backward compatible behavior of attaching the file to the root namespace occurs.

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.

1) Is it not possible that the library being pulled contains references to itself in the original namespace, rather than the new sub-namespace the require/include is forcing upon it?

Or do you anticipate that all such references would be converted?

What if, somehow, the library composes the reference from $data rather than hard-coded? (Which might be kind of crazy, but you know those PHP guys...)

2) Add more questions.

2012-03-06 - Initial proposal. 2012-03-08 - Dropped one of the pair after negative reception on the list to concentrate on the second.