Re: my last attempt at sanity with namespaces
| From: | Jessie Hernandez | Date: | Sun, 19 Oct 2008 18:10:38 +0000 |
| Subject: | Re: my last attempt at sanity with namespaces | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-41279@lists.php.net to get a copy of this message | ||
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)