From:
Operating system: Irrelevant
PHP version: 5.3.3
Package: Class/Object related
Bug Type: Feature/Change Request
Bug description:Modify Include and Require to specify namespace.
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.
--
Edit bug report at http://bugs.php.net/bug.php?id=52995&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52995&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52995&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52995&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52995&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52995&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52995&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52995&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52995&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52995&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52995&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52995&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52995&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52995&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52995&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52995&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=52995&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52995&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52995&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52995&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52995&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52995&r=mysqlcfg
