I'm not so sure about that. For example, class PDO is PHP core. Suppose I
create A\PDO. When PHP is asked for A\PDO and fails to find it then it will
die. Correct me if I'm wrong but I think it does NOT go looking for \PDO.
Another bugbear is classes will most likely be 1 class = 1 file. Functions
will probably end up being all functions of the namespace, 1 file.
Perhaps there's another way to do this that isn't as fraught with confusion,
though I have no idea of what the engine details are or if it's possible.
Suppose you have an autoloading function that triggers the first time a
namespace is mentioned to pull up definitions for that namespace. So when
the engine sees "namespace A;" declared for the first time It sees if any
autoloaders are present for namespace A. If yes, it fires them loading the
library files for the namespace.
Another, similar, approach is one I've been using in my own framework. When
the class autoloader first sees a namespace, it checks the filesystem for a
namespace definition file that holds functions and constants of the
namespace and then loads it (require_once) along with the requested class.
Since my framework is object oriented calls to a function that doesn't
belong to a specific class will not be emitted outside of a class method and
this has been sufficient to handle the problem for which this RFC is
supposed to solve within PHP 5.3. Just a thought.
On Wed, Aug 17, 2011 at 5:44 PM, Matthew Weier O'Phinney <
weierophin...@php.net> wrote:
>
>
> There's nothing saying you can't have the exact same situation right now
> with classes and autoloading, too.
>
> Example:
>
> namespace A;
>
> class ReflectionClass
> { /* ... */ }
>
> class MyClass
> { /* ... */ }
>
> What if you have an autoloader that, on encountering A\MyClass then
> loads that file? You've now redefined ReflectionClass for the A
> namespace.
>
> The main difference, of course, is that if ReflectionClass is not
> explicitly imported, PHP will barf and tell you it doesn't know about
> A\ReflectionClass.
>
> While I understand your objections, I think that after the functionality
> exists, there can be discussions about best practices -- e.g., putting
> one function per file when autoloading, or documenting when all
> functions for a given namespace will be in a single file. It's really a
> matter of the project educating its users -- I don't think it should be
> a blocker for implementing it at the language level, though.
>
>
> --
> Matthew Weier O'Phinney
> Project Lead | matt...@zend.com
> Zend Framework | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
