text: go to bug id or search bugs for
  New/Additional Comment:
  Description:
  ------------
  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
  Add a Pull Request
  I just noted that you can emulate what I propose in the current language with
  eval()
  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);
  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.