|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #52995 Modify Include and Require to specify namespace.
Submitted: 2010-10-05 23:50 UTC Modified: 2010-10-06 00:16 UTC
Avg. Score:3.0 ± 2.0
Reproduced:3 of 3 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (33.3%)
From: dmgx dot michael at gmail dot com Assigned:
Status: Open Package: Class/Object related
PHP Version: 5.3.3 OS: Irrelevant
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: dmgx dot michael at gmail dot com
New email:
PHP Version: OS:


 [2010-10-05 23:50 UTC] dmgx dot michael at gmail dot com
Would it be possible to modify include() and require() to take a second argument specifying the namespace scope that the included code will execute in.  If the argument is omitted the code executes in the root scope it always has. Any namespace paths in the file would be sub-namespaces of the namespace path specified in this new second argument.  Examples:

include('file.php', __NAMESPACE__); // exec in current namespace
require('other.php', '\\MyNamspace'); // exec in 'MyNamespace';
require_once('again.php'); // exec in global namespace for backward compat.

This change addresses a minor problem I hit while using namespaces with my template system. The template files are included into the function scope, but the code in those templates loses the namespace of the function that made the include call. I could namespace the templates, but they are primarily html files and so having a namespace header on them looks ugly.

I do not know if the loss of namespace is considered a bug in and of itself.

One powerful application of this addition is it would allow autoloaders to load classes into different namespaces. Instead of declaring the namespace of the class in the class file statically, the autoloader could determine the namespace it needs to load the class into to satisfy the path. This would also allow for dynamic subclassing of projects.

Consider framework with namespaces \Framework and \Project.  The former contains the default work files of the framework and the latter those of the project.  A call for a new class is issued to the autoloader from code executing in \Framework space looking for the Page class.  The autoloader is programmed to check the project files first to see if there's an override.  There is.  The file starts off with "class Page extends \Framework\Page" If include("Page.php" "\\Framework") is allowed then we will get a second call to the autoloader for the original framework file, but the path will be "\Framework\Framework\Page". With a little effort in the autoload writing this could be resolved and code execution could continue.

Not going to say how easy it would be to *debug*... but it does add a lot of flexibility into the mix.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2010-10-06 00:16 UTC] dmgx dot michael at gmail dot com
I just noted that you can emulate what I propose in the current language with 

eval( 'namespace '.$namespace.'; '.file_get_contents($path) );

Not usable in production I would imagine since eval is fairly slow compared to 
straight including (but I could be wrong);
 [2010-10-25 17:36 UTC] dmgx dot michael at gmail dot com
I played around with some test cases using eval to simulate the autoloaders case use I mentioned - but that's a no go because PHP dies if a second request for a class is raised while evaluating autoload code.  Unless this is changed so that PHP recalls the autoloader when this occurs the case study can't be applied which in turn makes the usefulness of this change partially moot.  It's still useful for the original corner case of template parsing but beyond that not.
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Thu Dec 01 18:05:54 2022 UTC