Jessie Hernandez wrote:
Hi Greg,
I've read through the posts and the RFC and am not sure if this was
discussed before, but there is one other proposal I'd like to throw out
there: why not require all classes that are inside namespaces to be
explicitly imported? This would follow the AS3 approach
(http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/statements.html#import).
I believe this would solve the issue with the namespace separator at
compile-time. The namespace separator can be left as :: and would only
be used in certain cases, such as when creating objects dynamically
(i.e. <code>$c = 'MyNs::MyClass'; $o = new $c;</code>). The double-colon
would work dynamically, since at runtime you can tell what's a namespace
and what's a class.
So the class resolution rules would change to the following:
1) If the class was explicitly use'd, then use that class.
2) If not, look for the class in the global namespace (this would
include internal classes).
If one wanted to have a custom Exception class inside a namespace, one
would first alias the core Exception class and then extend from that:
<?php
use Exception as PhpException;
class Exception extends PhpException {}
?>
Thoughts, comments?
Adding to this, I would require all _elements_, not just classes, to be
use'd (this is also in line with AS3). This would allow functions and
constants to also be namespaced. Any use of :: at compile-time would be
used to separate a class from a member. For example, you could never use
MyNs::MyClass::myMethod, but since a "use" statement is required, you
would use MyClass::myMethod directly.
--
Jessie Hernandez
Zend Certified Engineer (http://zend.com/zce.php?c=ZEND006359&r=222727282)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
